I wouldn’t worry too much about 3.5.
I’m so far out on in obscurity with this whole project that handling 4.x 
is quite enough! At least that version is most likely to be where any 
remnant interest may lie.

Thanks for a great effort. I too enjoyed it, even if maybe some might 
not understand oil beef.

I can't help believe that if this board were more publicly accessible 
i.e. web, more interest would pop up out of the woodwork. Newsgroups are 
so last century ..

- Bernie


On 19/5/17 8:44 pm, Michael Kennedy wrote:
> [MY apologies, Bernie - under Thunderbird, I hit Reply instead of
> Followup - Mike]
>
> ----------------------------------------------------------------
>
>> Apologies for forcing a bad argument - then retracting it!
>
> No probs!! All MOST enjoyable, IMO! We all (hopefully) learn in these
> exchanges.
>
> And - to clarify for lurkers - that theory that I stated previously
> might not be the FULL spec re the handling of single-field
> sec-indices... Eg, the behaviour definitely depends on the sort-order,
> but it might also depend on:
>   - the number and type(s) of field(s) in the primary key, and/or
>   - the type of the sec-field, and/or
>   - if the sec-field is among the primary fields,
>   - etc, etc.
>
>> Kevin Mitchell was simply saying out that the way the secondary index
>> indicators for single indexes is "really stupid".
>
> Yep - seems he was correct
>
>> Thanks for the sample files. Looks like the structure of X0 has changed
>> along the way.
>
> Dammit...
>
>> The old ones I have don't include a sort order string.
>> I'll have to add version checking for all files parsed.
>
> Dammit!
>
>> Maybe sort order wasn't an option in older versions?
>
> I don't know. I might have 3.5 hidden away somewhere, and if I find it,
> I'll check on the sort-order files.
>
>> Wow, such a simple question, such a long discussion to figure out! Well
>> done!
>>
>> Highlights the tremendous value of this board. Now if it could just be
>> web accessible to gain a broader audience ...
>
> Yep - pity that interest is so low. But, in this specific case, maybe
> this chat might be useful for anyone analysing Delphi apps, PDoxWin, etc...
>
> Best regards,
>   - Mike
>
>
>> On 18/5/17 10:51 pm, Michael Kennedy wrote:
>>> Bernie,
>>>
>>>> I'm not convinced ...
>>>
>>> 'Well Oil Beeee', but, from my tests, the Sort-Order seemed to be the
>>> ONLY factor
>>>
>>> In other lives, I have written some Indexing code (C, ASM, Pascal...
>>> probably extremely similar to how Paradox indexing works internally),
>>> and I'm surprised that the Paradox DB engine treats single-key and
>>> multi-key indices differently. However, maybe some sorting/searching
>>> code was written for the INTNL (and maybe other) sort-order, and then,
>>> with the remaining sort-orders (incl ASCII), perhaps it needs to treat
>>> each byte of a single-key as separate "keys", and perhaps this approach
>>> then triggers the multi-key logic, and we get the XGn/YGn files for
>>> single-key sec-indices?
>>>
>>> All total guesswork on my part
>>>
>>>> If it is a single field secondary index "Sec Key" is the first of the
>>>> fields names, in your sample at 0xe4. Kevin Mitchell: "This is really
>>>> stupid!".
>>>
>>> Sorry, I don't understand your point...
>>>
>>>> Sort order is stored at posn/offset/locn/byte 0x29
>>>> 0x00 = ASCII
>>>> 0xb7 = Intl
>>>> 0x82 = ?
>>>> 0xe6 = Nor/Dan
>>>> 0x0b = Swe/Fin
>>>> 0x5d = Span
>>>> 0x62 = PDOX_ANSII_Intl
>>>>
>>>> My single field sec index X0n and XGn files are all 0x00 (ASCII)
>>>
>>> If you have single-field sec-indices, PDox 4.5, creating X0n/Y0n files,
>>> with ASCII sort-order, then my theory is wrong.
>>>
>>>> Your sample X0n is 0xb7 (Intl)
>>>
>>> Yes.
>>>
>>>> This started as a simple WTF X0n, but until resolved I'm going to have
>>>> to fix my code to read X0n on the basis you may not be alone.
>>>
>>> Might be the best approach.
>>>
>>> Just in case they're useful to you, I've attached a small ZIP-file:
>>>   - IX-TEST.* are the files created under the INTNL sort-order.
>>>   - IX-TEST1.* are copies of the above, as per you previous requests.
>>>   - AX-TEST.* are the same files created under the ASCII sort-order.
>>>
>>> Obviously, I'm using the same SOM files, same INIs, same CFG, etc,
>>> etc... The only difference (I'm aware of!) is the ASCII/INTNL setting.
>>>
>>>> And yes, my body clock is sometimes set to Intl too.
>>>
>>> LOL!!
>>>
>>>   - Mike
>>>
>>>
>>>> On 18/5/17 3:42 am, Michael Kennedy wrote:
>>>>>> Well Oil Beef Hooked.
>>>>>
>>>>> LOL!!!!! (I hadn't seen that version - THANK YOU!).
>>>>>
>>>>>> I have no idea why your setup is producing X0n. It is definitely
>>>>>> working
>>>>>> differently to my bog-standard 4.5 setup.
>>>>>>
>>>>>> The only X0n's I have are in archives of 1996 or earlier, mostly pre
>>>>>> 1993. 4.5 came out Sep 1993, so that makes sense.
>>>>>>
>>>>>> Do any XGn's exist in any of your project folders?
>>>>>>
>>>>>> There must be a clue somewhere.
>>>>>
>>>>> I scanned over many old apps where I have X0n/XGn files, and I think
>>>>> we've solved this mystery - SORT ORDER!
>>>>>
>>>>> But, it would be nice if You/Steve could confirm...
>>>>>
>>>>> I think these are the rules (so far!):
>>>>>   - If the Sort-Order = ASCII, then ALL Sec-Index files are XGn/YGn,
>>>>> XHn/YHn, etc.
>>>>>   - If the Sort-Order = INTNL, then ALL single-field Sec-Index files
>>>>> are
>>>>> X0n/Y0n, X1n/Y1n, etc. And ALL multi-field Sec-Index files are
> XGn/YGn,
>>>>> XHn/YHn, etc. As per Paradox docs.
>>>>>   - I have not checked what other sort-orders produce (that's an
>>>>> exercise for the Student!).
>>>>>
>>>>> Mike
>>>>>
>>>>> PS: I thought you are in Aussi/NZ, and, if so, are you on the
>>>>> night-shift?
>>>>>
>>>>>
>>>>>
>>>>>> On 18/5/17 1:32 am, Michael Kennedy wrote:
>>>>>>>> Are you running "Standard" or "Compatible" File Format?
>>>>>>>> (CCP, Standard Settings)
>>>>>>>
>>>>>>> Standard
>>>>>>>
>>>>>>>   - Mike
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 17/5/17 8:10 pm, Michael Kennedy wrote:
>>>>>>>>>> OK, let's get serious..
>>>>>>>>>
>>>>>>>>> Thanks!!
>>>>>>>>>
>>>>>>>>>> Have a look at one of your X0n files with a hex viewer/editor.
>>>>>>>>>>
>>>>>>>>>> At posn 0x04 (4 dec) is file type. My X0n has 0x05.
>>>>>>>>>> An XGn file will be 0x08
>>>>>>>>>
>>>>>>>>> When you say "posn", I think you mean "offset", relative
to 0
>>>>>>>>> (rather
>>>>>>>>> than 1)? On this basis, I'm getting 0x05.
>>>>>>>>>
>>>>>>>>>> At posn 0x39 (57 dec) is the file version id. My X0n
has 0x04
>>>>>>>>>> (3.5),
>>>>>>>>>> adding weight to Steve's theory.
>>>>>>>>>> 0x03 = 3.0
>>>>>>>>>> 0x04 = 3.5
>>>>>>>>>> 0x09 = 4.5, or is it 4.x?
>>>>>>>>>> 0x0b = 5.x
>>>>>>>>>> 0x0c = 7.x
>>>>>>>>>>
>>>>>>>>>> What do you get?
>>>>>>>>>
>>>>>>>>> Seems I'm getting 09.
>>>>>>>>>
>>>>>>>>> Here's the only non-zero 256-byte blocks from my file:
>>>>>>>>>
>>>>>>>>> 000  10 00 00 08 05 02 03 00 - 00 00 01 00 01 00 01 00
>>>>>>>>> ................
>>>>>>>>> 010  01 00 49 00 00 03 DE 35 - CF 3C A6 38 CF 3C 00 00
>>>>>>>>> ..I....5.<.8.<..
>>>>>>>>> 020  00 04 00 03 00 00 FF 00 - FF B7 00 00 FF 45 44 F5
>>>>>>>>> .............ED.
>>>>>>>>> 030  70 37 CF 3C 68 37 CF 3C - 00 09 01 00 00 00 1F 0F
>>>>>>>>> p7.<h7.<........
>>>>>>>>> 040  00 00 00 00 00 00 00 00 - 00 01 00 00 00 00 00 00
>>>>>>>>> ................
>>>>>>>>> 050  00 03 01 00 00 00 20 00 - 09 01 09 01 00 00 00 00
......
>>>>>>>>> .........
>>>>>>>>> 060  39 91 B0 4A 05 00 9E 00 - 00 00 52 03 01 01 A6 00
>>>>>>>>> 9..J......R.....
>>>>>>>>> 070  00 00 00 00 00 00 00 00 - 01 0A 03 02 03 02 03 02
>>>>>>>>> ................
>>>>>>>>>
>>>>>>>>> 080  84 37 CF 3C D3 37 CF 3C - DB 37 CF 3C DE 37 CF 3C
>>>>>>>>> .7.<.7.<.7.<.7.<
>>>>>>>>> 090  E1 37 CF 3C 49 58 2D 54 - 45 53 54 2E 58 30 33 00
>>>>>>>>> .7.<IX-TEST.X03.
>>>>>>>>> 0A0  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
>>>>>>>>> ................
>>>>>>>>> 0B0  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
>>>>>>>>> ................
>>>>>>>>> 0C0  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
>>>>>>>>> ................
>>>>>>>>> 0D0  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
>>>>>>>>> ................
>>>>>>>>> 0E0  00 00 00 53 65 63 20 4B - 65 79 00 49 31 00 49 32
...Sec
>>>>>>>>> Key.I1.I2
>>>>>>>>> 0F0  00 48 69 6E 74 00 03 00 - 02 00 03 00 04 00 69 6E
>>>>>>>>> .Hint.........in
>>>>>>>>>
>>>>>>>>> 100  74 6C 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
>>>>>>>>> tl..............
>>>>>>>>> 110  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
>>>>>>>>> ................
>>>>>>>>> 120  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
>>>>>>>>> ................
>>>>>>>>> 130  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
>>>>>>>>> ................
>>>>>>>>> 140  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
>>>>>>>>> ................
>>>>>>>>> 150  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
>>>>>>>>> ................
>>>>>>>>> 160  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
>>>>>>>>> ................
>>>>>>>>> 170  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
>>>>>>>>> ................
>>>>>>>>>
>>>>>>>>> 800  00 00 00 00 20 00 61 61 - 00 00 00 00 00 00 00 00
....
>>>>>>>>> .aa........
>>>>>>>>> 810  80 01 80 02 80 01 62 62 - 00 00 00 00 00 00 00 00
>>>>>>>>> ......bb........
>>>>>>>>> 820  80 02 80 03 80 01 63 63 - 00 00 00 00 00 00 00 00
>>>>>>>>> ......cc........
>>>>>>>>> 830  80 03 80 04 80 01 00 00 - 00 00 00 00 00 00 00 00
>>>>>>>>> ................
>>>>>>>>> 840  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
>>>>>>>>> ................
>>>>>>>>> 850  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
>>>>>>>>> ................
>>>>>>>>> 860  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
>>>>>>>>> ................
>>>>>>>>> 870  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
>>>>>>>>> ................
>>>>>>>>>
>>>>>>>>>> I have no idea how legacy 3.5 sec index files were
treated at
>>>>>>>>>> upgrade
>>>>>>>>>> through various versions 4.
>>>>>>>>>>
>>>>>>>>>> More tests:
>>>>>>>>>>
>>>>>>>>>> Copy a table which has a X0n: X0n is copied
>>>>>>>>>
>>>>>>>>> All the files (DB, PX, X03, Y03) are copied, TOTALLY unchanged!
>>>>>>>>>
>>>>>>>>> Also slightly interesting, because, the header inside each
of the
>>>>>>>>> copied
>>>>>>>>> files still contains the filename of the original file
(not its
> own
>>>>>>>>> (copied) name!)... presumably this filename is only a useless
>>>>>>>>> "comment"-field...
>>>>>>>>>
>>>>>>>>>> Show Family: no speedup (secondary index) listed. Looks
like 4.5
>>>>>>>>>> isn't
>>>>>>>>>> seeing the X0n.
>>>>>>>>>
>>>>>>>>> Both families (original and copy) DO show the Speedup entry.
>>>>>>>>>
>>>>>>>>>> Restructure the copied table: X0n timestamp not updated.
Looks
>>>>>>>>>> like
>>>>>>>>>> 4.5
>>>>>>>>>> is not updating the X0n file.
>>>>>>>>>
>>>>>>>>> In my case, Restructure (on both tables) DOES update the
>>>>>>>>> timestamp of
>>>>>>>>> all files.
>>>>>>>>>
>>>>>>>>>> ** 4.5 producing X0n seems plain wrong **
>>>>>>>>>
>>>>>>>>> Or ** believing so is plain wrong **
>>>>>>>>>
>>>>>>>>> Seriously, if you want my files, I can ZIP 'em up and email
> them to
>>>>>>>>> you
>>>>>>>>> or, if others might be interested, I'll place them anywhere
>>>>>>>>> convenient.
>>>>>>>>> Or, I wonder if it's OK to attach them to a post here?
>>>>>>>>>
>>>>>>>>>   - Mike
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 17/5/17 1:28 am, Michael Kennedy wrote:
>>>>>>>>>>> On 16/05/2017 15:52, Bernie van't Hof wrote:
>>>>>>>>>>>> Done. Result: XG0, YG0.
>>>>>>>>>>>
>>>>>>>>>>> WOW!!!!!
>>>>>>>>>>>
>>>>>>>>>>> I'm stumped (again!).
>>>>>>>>>>>
>>>>>>>>>>> From my reading of some PDox DOCs, my result (X0n/Y0n)
is
>>>>>>>>>>> correct.
>>>>>>>>>>> So, I
>>>>>>>>>>> think your conversion code should also allow for
X0n/Y0n,
>>>>>>>>>>> X1n/Y1n,
>>>>>>>>>>> etc.
>>>>>>>>>>>
>>>>>>>>>>> I hope that the DB update engine, and the Query
engine, will
>>>>>>>>>>> detect
>>>>>>>>>>> and
>>>>>>>>>>> use both sets of sec-idx files. (And I don't know
of any easy
>>>>>>>>>>> way to
>>>>>>>>>>> prove this - apart from getting a HUGE DB, and
updating it, and
>>>>>>>>>>> then
>>>>>>>>>>> check the timings of queries on it - with and without
the
>>>>>>>>>>> sec-indices).
>>>>>>>>>>>
>>>>>>>>>>>> I originally suspected X0n were old because
the only ones I
>>>>>>>>>>>> could
>>>>>>>>>>>> find
>>>>>>>>>>>> had very old timestamps like 1996.
>>>>>>>>>>>>
>>>>>>>>>>>> If you Alt-F10 V(alue) version() Enter what
do you get?
>>>>>>>>>>>
>>>>>>>>>>> 4.5
>>>>>>>>>>>
>>>>>>>>>>> Interesting that you ask - I think that the "version"
is held
>>>>>>>>>>> in a
>>>>>>>>>>> few
>>>>>>>>>>> places inside PDoxDOS, and I've often seen the
same EXE showing
>>>>>>>>>>> different versions (4.02 or 4.5), in different
places. (I never
>>>>>>>>>>> investigated - maybe CFG files, maybe INI files,
maybe inside
>>>>>>>>>>> EXEs,
>>>>>>>>>>> maybe splash screens, etc).
>>>>>>>>>>>
>>>>>>>>>>> So, what next...
>>>>>>>>>>>
>>>>>>>>>>> My PDox config is for DD/MM/YYYY dates, "UK" settings
(where
>>>>>>>>>>> applicable), so I wonder what's causing this anomaly?
>>>>>>>>>>>
>>>>>>>>>>> Dammit.....
>>>>>>>>>>>
>>>>>>>>>>>   - Mike
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On 16/5/17 8:37 pm, Michael Kennedy wrote:
>>>>>>>>>>>>>> Did the test as suggested on 4.5 rig
by creating a new table
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> primary key, then viewing and adding
a single column
> secondary
>>>>>>>>>>>>>> index.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Result:
>>>>>>>>>>>>>> DB, PX, XG0, YG0
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So looks like Steve's answer is correct!
>>>>>>>>>>>>>
>>>>>>>>>>>>> ?????
>>>>>>>>>>>>>
>>>>>>>>>>>>> See script below...
>>>>>>>>>>>>>
>>>>>>>>>>>>>   - Mike
>>>>>>>>>>>>>
>>>>>>>>>>>>> ; Paradox DOS 4.5 - very complex script
>>>>>>>>>>>>> ;
>>>>>>>>>>>>> ; It creates an indexed table "Ix-test"
- change that name, if
>>>>>>>>>>>>> needed.
>>>>>>>>>>>>> ; Three fields in total - two in the primary
index, and a data
>>>>>>>>>>>>> field!
>>>>>>>>>>>>> ; It inserts a few data records.
>>>>>>>>>>>>> ; It creates a single-field Sec-Index,
on the Data-field.
>>>>>>>>>>>>> ; That's it!
>>>>>>>>>>>>> ;
>>>>>>>>>>>>> ; After running it, check what files are
created...
>>>>>>>>>>>>> ; Is the Sec-Index called *.X0n/*.Y0n or
*.XGn/*.YGn ?
>>>>>>>>>>>>> ; I get X0n/Y0n..... If you get XGn/YGn,
we should
> investigate.
>>>>>>>>>>>>> ;
>>>>>>>>>>>>> ;     - Mike Kennedy, May, 2017
>>>>>>>>>>>>>
>>>>>>>>>>>>> ClearAll
>>>>>>>>>>>>> {Create} {Ix-test}
>>>>>>>>>>>>>   "I1" Right  "S*" Down
>>>>>>>>>>>>>   "I2" Right  "S*" Down
>>>>>>>>>>>>>   "D1" Right  "A10"
>>>>>>>>>>>>> Do_It!
>>>>>>>>>>>>>
>>>>>>>>>>>>> {View} {Ix-test} CoEditKey
>>>>>>>>>>>>>   "1" Right  "2" Right  "aa" Down
>>>>>>>>>>>>>   "2" Right  "3" Right  "bb" Down
>>>>>>>>>>>>>   "3" Right  "4" Right  "cc"
>>>>>>>>>>>>> Do_It!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Menu {Modify} {Index} {Ix-test}  "Sec-Idx1"
Enter Enter Enter
>>>>>>>>>>>>> Down Down "1" Do_It!
>>>>>>>>>>>>> ClearAll
>>>>>>>>>>>>>
>>>>>>>>>>>>>
> -----------------------------------------------------------------------------------
>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 16/5/17 8:34 am, Michael Kennedy
wrote:
>>>>>>>>>>>>>>> On 15/05/2017 22:14, Steven Green
wrote:
>>>>>>>>>>>>>>>> if there are active x0* files,
paradox won't kill them, but
>>>>>>>>>>>>>>>> they're
>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>> 3.x tables that were upgraded
to 4.x tables.. a 4.x table
>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>> xg*
>>>>>>>>>>>>>>>> files, then xh* files if it
goes thru the alphabet.. yes, I
>>>>>>>>>>>>>>>> have an
>>>>>>>>>>>>>>>> app
>>>>>>>>>>>>>>>> here, that I'm working on,
that did that
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Re the x0*/y0* files... just for
the heck of it! - can you
>>>>>>>>>>>>>>> check
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> following on any 4.02/4.5 rig:
>>>>>>>>>>>>>>>   - Make a temp/test copy of any
table (which does not have
>>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>> X0*/Y0*
>>>>>>>>>>>>>>> files!).
>>>>>>>>>>>>>>>   - On it, create one (or more)
Sec-Indices, but... flag
> just
>>>>>>>>>>>>>>> ONE
>>>>>>>>>>>>>>> field
>>>>>>>>>>>>>>> for the/each sec-index.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think this will create new X0*/Y0*
files (instead of the
>>>>>>>>>>>>>>> usual
>>>>>>>>>>>>>>> multi-field XG*/YG* ones)!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   - Mike
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Steven Green
>>>>>>>>>>>>>>>> Myrtle Beach, South Carolina,
USA
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://www.OasisTradingPost.com
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Collectibles and Memorabilia
>>>>>>>>>>>>>>>> Vintage Lego Sets and Parts
>>>>>>>>>>>>>>>> - and Paradox support, too
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "Michael Kennedy"  wrote in
message
>>>>>>>>>>>>>>>> news:5919cd02@pnews.thedbcommunity.com...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> yes, they're the old 3.x
sec indexes.. the 4.x sec index
>>>>>>>>>>>>>>>>> pairs
>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>> .xg*
>>>>>>>>>>>>>>>>> and .yg*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Steve - the .X0n/.Y0n files
are still created by 4.5 (and,
>>>>>>>>>>>>>>>> presumably,
>>>>>>>>>>>>>>>> for all Paradox/BDE/Delphi
tables), for single-field
>>>>>>>>>>>>>>>> sec-indices.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Also, I just checked:
>>>>>>>>>>>>>>>>   - The "X" files have the
"DB" structures,
>>>>>>>>>>>>>>>>   - The "Y" files are the "PX"
equivalents.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Mike
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://www.OasisTradingPost.com
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Collectibles and Memorabilia
>>>>>>>>>>>>>>>>> Vintage Lego Sets and Parts
>>>>>>>>>>>>>>>>> - and Paradox support,
too
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> "Bernie van't Hof"  wrote
in message
>>>>>>>>>>>>>>>>> news:59176eda$1@pnews.thedbcommunity.com...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I have some .x0n files
in archives. I suspect they are
>>>>>>>>>>>>>>>>> old as
>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>> appear in the current database,
What's curious about
>>>>>>>>>>>>>>>>> them is
>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>> contain secondary index
detail like XGn etc.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Any ideas? Could they be
a relic of pre 4.5 or 4.0?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>> Bernie
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>> This email has been checked
for viruses by Avast antivirus
>>>>>>>>>>>>>>>>> software.
>>>>>>>>>>>>>>>>> https://www.avast.com/antivirus
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>