Actually I take back my discord.

What I have does not conflict with your idea at all!

- Bernie

On 18/5/17 9:08 am, Bernie van't Hof wrote:
> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>