If the difference is within the first 8 characters, you have no problem:

RacingMainInt.DB
BackRacingMainInt.DB

...no conflict.  Otherwise, risk of conflict.  Conflict is not 
guaranteed - depends on secondary indexes and on the sequence in which 
files are created.  The problem requires a very specific set of 
circumstances.

As long as Windows 10 still creates short file names with the same 
rules, and as long as the BDE (version that you're using) still uses 
short names, it's still a problem.

As to your second question, I've never done it, but it does seem like 
you've got a good candidate for an SQL server.

Liz


On 27 Jan 2019 23:37, Robert MacMillan wrote:
> 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
>>>
>>>