I'm not convinced ...

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!".

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)
Your sample X0n is 0xb7 (Intl)


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.

And yes, my body clock is sometimes set to Intl too.

-Bernie

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