Alaska Software Inc. - CDX OrdListAdd Issue
Username: Password:
AuthorTopic: CDX OrdListAdd Issue
Jonathan LeemingCDX OrdListAdd Issue
on Mon, 30 Oct 2017 12:17:23 -0700
Hi,

I am converting my application from DBF/NTX to DBF/CDX and believe I 
have found a problem with OrdListAdd() or OrdNumber().

It is my understanding that OrdNumber() should return a number that 
reflects the opening sequence of a given index file.  However if I open 
a DBF file and then activate 10 index files and subsequently try to 
reference a particular tag by the order in which it was open I may get 
the wrong tag.

I have created a small example that shows this problem as well as the 
dbf & cdx files.  In theory when the program is run the two columns of 
numbers should match.  I first found the issue while using ADSDBE for 
FOX files but found that the same problem was occurring if I was not 
using ADS.

Regards... Jonathan


CdxCheck.prg
BILLHD.CDX
BILLHD.DBF
Andreas Gehrs-Pahl
Re: CDX OrdListAdd Issue
on Mon, 30 Oct 2017 16:03:13 -0400
Jonathan,

>It is my understanding that OrdNumber() should return a number that 
>reflects the opening sequence of a given index file.

That is not the case with CDX Tags. They are always in the same order, which 
is the order in which they were created in the CDX file.

That also means that you don't need to -- and actually shouldn't -- open 
individual Tags when using CDX Index files. The (first) For-Next loop in 
your code should therefore be replaced by this single line of code:

OrdListAdd("BILLHD")

Some additional gotchas: If you add a new Index Tag to an existing CDX Index 
Bag (or File), the new Tag is always added to the file, even if a Tag with 
the same name already exists. This means that the CDX file will continue to 
grow with multiple copies of Tags, unless you delete the entire CDX file, 
before (re-)creating an existing index tag using OrdCreate().

This also means that the best way to deal with the selection of individual 
Tags is by using the Tag Name, rather than ordinal positions, as the ordinal 
position is always determined by the contents of the CDX file, which isn't 
always predictable.

Using DbSeek(cKeyValue, lSoftSeek, cTagName) to seek with a specific Index 
Tag or selecting a specific order with OrdSetFocus(cTagName) is a much 
better way to handle this, and using a Tag Name rather than an arbitrary 
(ordinal position) number is much easier to read and debug.

Hope that helps,

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas@AbsoluteSoftwareLLC.com
web:   http://www.AbsoluteSoftwareLLC.com
[F]:   https://www.facebook.com/AbsoluteSoftwareLLC
Jonathan LeemingRe: CDX OrdListAdd Issue
on Mon, 30 Oct 2017 15:24:26 -0700
On 10/30/2017 1:03 PM, Andreas Gehrs-Pahl wrote:
> Jonathan,
> 
>> It is my understanding that OrdNumber() should return a number that
>> reflects the opening sequence of a given index file.
> 
> That is not the case with CDX Tags. They are always in the same order, which
> is the order in which they were created in the CDX file.
> 
> That also means that you don't need to -- and actually shouldn't -- open
> individual Tags when using CDX Index files. The (first) For-Next loop in
> your code should therefore be replaced by this single line of code:
> 
> OrdListAdd("BILLHD")
> 
> Some additional gotchas: If you add a new Index Tag to an existing CDX Index
> Bag (or File), the new Tag is always added to the file, even if a Tag with
> the same name already exists. This means that the CDX file will continue to
> grow with multiple copies of Tags, unless you delete the entire CDX file,
> before (re-)creating an existing index tag using OrdCreate().
> 
> This also means that the best way to deal with the selection of individual
> Tags is by using the Tag Name, rather than ordinal positions, as the ordinal
> position is always determined by the contents of the CDX file, which isn't
> always predictable.
> 
> Using DbSeek(cKeyValue, lSoftSeek, cTagName) to seek with a specific Index
> Tag or selecting a specific order with OrdSetFocus(cTagName) is a much
> better way to handle this, and using a Tag Name rather than an arbitrary
> (ordinal position) number is much easier to read and debug.
> 
> Hope that helps,
> 
> Andreas
> 
Hi Andreas... and thanks... my education continues!

The numeric reference to the tag is a carry over from a main file 
handling routine that was originally created in my Clipper days.  I 
found the issue yesterday when testing some reports.  Since then I have 
been doing the same as you are suggesting and agree that 
OrdSetFocus(cTagName) is a much better practice.  So far I'm about 
halfway though all the instances.

Also thanks for pointing out that I only need to do one 
OrdListAdd(cIndexFile)... I'll clean my glasses before I next read the 
documentation.

Thanks Once Again... Jonathan
Jim LeeRe: CDX OrdListAdd Issue
on Tue, 31 Oct 2017 18:52:01 +0100
hi,

i wonder about your BILLHD.DBF while it have 03H in DBF-Header which mean 
NTX

Question : what Type of Fox DBF do you want to use ?
Andreas Gehrs-Pahl
Re: CDX OrdListAdd Issue
on Tue, 31 Oct 2017 19:33:37 -0400
Jim,

>i wonder about your BILLHD.DBF while it have 03H in DBF-Header which mean NTX

That is incorrect. The first byte in the database header (0x03) means that 
this is a standard (dBaseIII/IV/FoxPro) DBF file without a memo file.

Other options include (but are not limited to):
* FoxBase: 0x02
* dBaseIV: 0x04
* dBaseV: 0x05
* VFP: 0x30
* FoxPro/dBaseIII with (DBT) memo file: 0x83
* dBaseIV with memo file: 0x8B
* dBaseIV with SQL Table: 0x8E
* FoxPro with (FMP/FPT) memo file: 0xF5

There is no indication in the standard (dbaseIII) DBF header format if an 
NTX, CDX, or any other kind of Index file exists!

The 29th byte might indicate that a production MDX or CDX index file exists 
or not: 0x00 (no) or 0x01 (yes). In VFP it might also indicate if a memo 
file exists (0x02) or if a Database Container (DBC) (0x04) or DBC with memo 
and indexes (0x07) exists.

In the "BILLHD.DBF" database file, the 29th byte is 0x00, though.

The 30th byte, which is (also) 0x03 in the "BILLHD.DBF" database file, 
indicates which Code Page for FoxPro/VFP tables is used, and 0x03 means: 
* CodePage 1251 -- Windows ANSI

Hope that helps,

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas@AbsoluteSoftwareLLC.com
web:   http://www.AbsoluteSoftwareLLC.com
[F]:   https://www.facebook.com/AbsoluteSoftwareLLC
Jim LeeRe: CDX OrdListAdd Issue
on Wed, 01 Nov 2017 03:12:56 +0100
ooops ... YES you are right that FOXCDX without Memo have 03H
Andreas Gehrs-Pahl
Re: CDX OrdListAdd Issue
on Wed, 01 Nov 2017 18:35:35 -0400
Jim,

>ooops ... YES you are right that FOXCDX without Memo have 03H

Actually, 03H could mean DBFNTX, DBFCDX, FOXNTX, as well as FOXCDX. As I 
tried to point out in my previous post, the DBF header has absolutely no 
indication or relationship to what type of Index file might or might not 
be associated with the database file!

There are only four different values possible for the first byte in DBF 
file headers that were created by an Alaska Xbase++ program:

* 03H (DBF without Memo file, created by DBFDBE or FOXDBE in Fox2x Mode)
* 83H (DBF with Memo file, created by DBFDBE)
* F5H (DBF with Memo file, created by FOXDBE in Fox2x Mode)
* 30H (DBF with or without Memo file, created by FOXDBE in VFP Mode)

Each of those databases might -- or might not -- have NTX and/or CDX Index 
files associated with it!

Hope that clarifies it.

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas@AbsoluteSoftwareLLC.com
web:   http://www.AbsoluteSoftwareLLC.com
[F]:   https://www.facebook.com/AbsoluteSoftwareLLC