IIRC.. I know there was an issue with long file names with pdoxdos and 
pdoxwin using the same files.. I know there was an issue with one version of 
Win itself, I think it was Win2000.. other than that, the various versions 
of BDE and Win seem to play nicely together


--

Steven Green
Myrtle Beach, South Carolina, USA

http://www.OasisTradingPost.com

Collectibles and Memorabilia
Vintage Lego Sets and Parts
- and Paradox support, too
"Liz McGuire"  wrote in message 
news:2f7da20b-4b85-7e35-acdf-0f29fbc253a5@paradoxcommunity.com...

I seriously doubt the BDE's been updated since 2012, and I know I was
not using 16-bit BDE when I made that post and the tests used to prove
the problem.

But if the BDE has been updated to use the Windows long file name rather
than the Windows short file name, or if you're using a version of
Windows that somehow makes short file names differently, then it
wouldn't be a problem, but I kinda doubt it.

FWIW,
Liz

On 28 Jan 2019 05:19, Steven Green wrote:
> yes, the old long file name errors should be a thing of the past.. the
> biggest issues were a result of multiple versions of everything, which
> should no longer be the case.. if there happens to be a stray
> installation of pdoxdos or 16-bit bde, that might still apply
>
> --
>
> Steven Green
> Myrtle Beach, South Carolina, USA
>
> http://www.OasisTradingPost.com
>
> Collectibles and Memorabilia
> Vintage Lego Sets and Parts
> - and Paradox support, too
> "Tom Krieg"  wrote in message news:5c4ec1d1$1@pnews.thedbcommunity.com...
>
> From what Liz said, it's not a Windows thing it's a BDE thing. The BDE
> has not been updated or patched since 5.2 (anyone remember when that
> was?) so what Liz said still applies.
>
> I strongly recommend PostgreSQL because it plays really nicely with
> Paradox and because the pgODBC driver is maintained and kept up to date.
> PG is now at version 10 and there are a lot of nice things now. "gin"
> indexes (Generalized Inverted Index) that allow you to index words in
> and search text fields and documents quickly is just one. I have built
> an Australian address database from the Federal GNAF address database
> with over 14 million records and an address search (which can bring up
> to 14  or 15 choices based on a type-ahead search) takes 65ms against a
> gin index.
>
> In terms of queries, pgSQL and functions will let you run rings around
> Paradox queries. Especially if you build the pgSQL on the fly, depending
> on the results of the last one.
>
> I would agree that it would be easy to export data from a PG database
> into a Paradox table (or CSV or Excel) and vice versa into PostgreSQL
> which can be automated. Your application would also be a whole lot more
> stable if it were transferred to PG. In fact, if your application were
> transferred to PG and Visual Studio/.NET CORE/C# you wouldn't have to
> worry about Windows, and you could have a mobile (Android/iOS) sub-app
> to use while you're at the track.
>
> Start by writing a pgSQL interface and see how you go.
>
> Robert MacMillan wrote on 28/01/2019 5:37 PM:
>> This is a post from a long time ago. And I always believe Liz.
>>
>> However I am in the process of rewriting a whole lot of stuff because
>> it has grown over time and it can be made much more efficient. As part
>> of that re write I would like to revisit this topic.
>>
>> I have been using long file names for a very long time because they
>> existed before this user group. And I have tables called things like
>> "RacingMainInt.db" and "RacingMainIntBack.db" and so on. They all run
>> just fine and give me very little problem and that was under Windows
>> XP previously and Windows 10.
>>
>> So my first question is does this advice still apply using Windows 10
>> or has it all become redundant with the later OS's. So Windows 7
>> onward effectively? I suspect not because BDE predates those OS's.
>>
>> Also as a secondary question.
>>
>> I am also wondering if it is also time to go to storing the main
>> information in either one of the sql variants or PostGRE or Firebird
>> or something else that people might like to suggest. One of the
>> reasons is that one of the people that I work with who does stuff in
>> sql came up with the most monstrous table I have ever seen recently.
>> About 550 fields wide and we need to be able to share data. Many of
>> those fields are not of great interest or value so I am thinking about
>> a process that goes something like this.
>>
>> At a local level as the race fields come in creating a coded Index
>> Table which assigns a unique runnerID. So Long Int as a key.
>> .
>> Then processing all my information locally in Paradox as I do
>> currently on a daily basis.
>> .
>> Then pushing the local information into an sql or other format.
>> .
>> And then on a daily basis pulling the fields and tables I want from
>> sql or whatever might be the best storage option for local processing
>> by Paradox. The need to process locally is that Paradox can do things
>> with queries that no other language is able to do and I use that code
>> extensively. In fact I have written code that self learns.
>>
>> Thanks in advance.
>>
>> On 26/11/2012 9:08 AM, Liz McGuire wrote:
>>> Do Not Use Long File Names With Paradox!
>>>
>>> There is no fix.  The BDE does not comprehend long file names, so it
>>> will use the Windows-generated short name (Someth~1.DB).
>>>
>>> Do Not Use Long File Names With Paradox!
>>>
>>> That is the start and the end of it.  This is most especially true of
>>> tables because tables consist of multiple files and the BDE expects all
>>> those files to have the same name, but different extensions.  However,
>>> because Windows doesn't know, care or follow the BDE rules, it can name
>>> things such that it confuses the BDE to the point of not functioning.
>>> Take this example:
>>>
>>> PurchaseOrders.DB        > PURCHA~1.DB
>>> PurchaseOrderDetails.DB  > PURCHA~2.DB
>>> PurchaseOrders.PX        > PURCHA~1.PX
>>> PurchaseOrderDetails.PX  > PURCHA~2.PX
>>>
>>> ...good so far, but at some point, you add a secondary index to
>>> PurchaseOrderDetails.DB, so you can sort on the purchase order number,
>>> for example.  This would create these two files:
>>>
>>> PurchaseOrderDetails.XG0
>>> PurchaseOrderDetails.YG0
>>>
>>> ...to which Windows promptly assigns these two "short" names:
>>>
>>> PURCHA~1.XG0
>>> PURCHA~1.YG0
>>>
>>> ...and now the BDE thinks that PurchaseOrders.DB has a secondary index
>>> (which will break everything because that table doesn't have a secondary
>>> index and the secondary index is not compatible with that table and your
>>> app needs a secondary index for the detail table, but the BDE can't find
>>> a secondary index for the detail table).
>>>
>>> So, in short: Do Not Use Long File Names With Paradox!
>>>
>>> Liz
>>>
>>>
>>> On 25 Nov 2012 13:19, Bob Eccles wrote:
>>>> Hi,
>>>>
>>>> I've been using Paradox since the DOS versions, but since Windows 95,
>>>> I've
>>>> never seen this problem:
>>>>
>>>> When I create a table, or rename one, if I try to give it a name of 11
>>>> letters or more, the whole system hangs, and I have to close the
>>>> Paradox
>>>> window, using Windows Task Manager.
>>>>
>>>> If it's 10 characters or less, no problem, but it won't accept 11 or
>>>> more.
>>>>
>>>> If I give the table a short name, then close Paradox and rename the
>>>> files to
>>>> a longer name, that's not a problem - Paradox still opens the table as
>>>> usual. It also has no problem with the dozens of tables I've created
>>>> over
>>>> the years, with longer names.
>>>>
>>>> I'm using (by choice) Paradox 7, and Windows XP.
>>>>
>>>> Has anyone come across this problem, or know of a cause/fix?
>>>>
>>>> Bob Eccles
>>>>
>>>>
>