[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
 >>>>>>>>>>>>>>>>
 >>>>>>>>>>>>>>>