Paradox Community

Items in pnews.paradox-dos

Subject:Re: X0n files
Date:Sat, 20 May 2017 20:05:40 +1000
From:Bernie van't Hof <berniev@bje.com.au>
Newsgroups:pnews.paradox-dos
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?

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


Copyright © 2004 thedbcommunity.com