Author | Topic: CDX OrdListAdd Issue | |
---|---|---|
Jonathan Leeming | CDX 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 Leeming | Re: 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 Lee | Re: 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 Lee | Re: 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 |