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

idxtest.zip