Looks like that list goes up to Pdox v4.0

On 01/28/2019 11:02 AM, Steven Green wrote:
> http://edn.embarcadero.com/article/15159
> 
> but I'm sure this doesn't cover everything we need to know :-)
> 
> -- 
> 
> Steven Green
> Myrtle Beach, South Carolina, USA
> 
> http://www.OasisTradingPost.com
> 
> Collectibles and Memorabilia
> Vintage Lego Sets and Parts
> - and Paradox support, too
> "Leslie"  wrote in message news:5c4f22f3$1@pnews.thedbcommunity.com...
> 
> I think the BDE has a 25 character name restriction on tables.
> There is a list of BDE/Paradox limits floating around somewhere.
> Leslie.
> 
> 
> On 28/01/2019 6:48 PM, Tom Krieg wrote:
>> 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
>>>>>
>>>>>
> 
> ---
> This email has been checked for viruses by AVG.
> https://www.avg.com