> Re change to intl - I have forgotten how!

Oh, simple...

In the main PDox folder, there are *.SOR files.

For Paradox-Interactive:
   - The active sort-order is in PARADOX.SOR.
   - Close Pdox-Interactive.
   - Maybe keep a backup of PARADOX.SOR.
   - Copy whichever SOR file you prefer to PARADOX.SOR
   - Start Paradox, etc!!!
   - Close when done!
   - Rename that backup to PARADOX.SOR.

For Paradox-Runtime the exact same steps apply, but the active SOR file 
is named PDOXRUN.SOR.

   - Mike


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