Apologies for forcing a bad argument - then retracting it!

Kevin Mitchell was simply saying out that the way the secondary index 
indicators for single indexes is "really stupid".

Thanks for the sample files. Looks like the structure of X0 has changed 
along the way. The old ones I have don't include a sort order string. 
I'll have to add version checking for all files parsed.

Maybe sort order wasn't an option in older versions?

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

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