Thanks.

Re change to intl - I have forgotten how!

- Bernie


On 20/5/17 10:01 pm, Michael Kennedy wrote:
>> Any chance of doing one more single secondary index test file, only this
>> time generate the index by doing view, Alt-S on a column?
>
> Pleasure...
>
> As attached.
>
> I copied IX-TEST1 to IX-TEST2, added a few more data-fields (Date, S, N,
> $), and did Alt-S on each field:
>   - Alt-S on field I1 (Primary #1) didn't give an error, and ran, but I
> think it created nothing (as would be expected).
>   - On some of the other fields, I got a Cancel/OK option, because the
> process might take a long time (I had 3 tiny records in the tiny table!).
>   - In all cases, X0n/Y0n files were created.
>
> The Family view shows all of these as maintained sec-indices - as expected.
>
> It might be interesting if you switch your rig to INTNL, and see if you
> get the same results?
>
>   - 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
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>