using ADD() with dBaseIV - help needed

[keithmcalpine]

i need to add records to data files of Cougar Mountain Software (CMS) Accounting for Windows.

i imported a dBaseIV file into a Clarion dictionary. i wrote a procedure that:
opens the file using Open(filename,ReadWrite+DenyAll)
packs the file using Pack(filename)
adds records to the file using Add(filename)
closes the file using Close(filename)

no errors were posted.
when browsing the file with my program, i can see the added records in the browse, but when i browse the file with CMS, the records don't show. i've made sure that it isn't a range limit problem in CMS. the records were primed with values similar to existing records added by CMS.

i know that records won't show when dBase marks them deleted. i suspect that this might be the problem but i need confirmation before seeking a solution. i don't have a lot of experience with dBase, so, anything can be wrong.

keith

 

[hhb]

Your problem is that you only import the file definition and not the indexes the cms uses.

You see the records in a browse, but when cms asks the keys (from cms) a limited result set is returned....

You have to import de keys in you definition, so that if you add to the file, the keys are updates as well.

Maurice H.

 

[keithmcalpine]

Here is the CMS file declaration imported in Clarion:


BFPAI___ FILE,DRIVER('dBase4'),NAME(GloBFPath),PRE(AI___),BINDABLE,THREAD
KEY_APTITRNUM KEY(AI___:APTITRNUM),NAME('APTITRNUM|BFPAI___.MDX=C[STR(APTITRNUM,5,0)],FOR[.NOT.DELETED()]')
KEY_APTIVENDOR KEY(AI___:APTIVENDOR,AI___:APTITRNUM),DUP,NAME('APTIVENDOR|BFPAI___.MDX=C[UPPER(APTIVENDOR)+STR(APTITRNUM,5,0)],FOR[.NOT.DELETED()]')
KEY_APTIINVOIC KEY(AI___:APTIINVOIC,AI___:APTITRNUM),DUP,NAME('APTIINVOIC|BFPAI___.MDX=C[UPPER(APTIINVOIC)+STR(APTITRNUM,5,0)],FOR[.NOT.DELETED()]')
KEY_APTIPONUM KEY(AI___:APTIPONUM,AI___:APTITRNUM),DUP,NAME('APTIPONUM|BFPAI___.MDX=C[UPPER(APTIPONUM)+STR(APTITRNUM,5,0)],FOR[.NOT.DELETED()]')
KEY_APTIBANK KEY(AI___:APTIBANK,AI___:APTIIMMED),DUP,NAME('APTIBANK|BFPAI___.MDX=C[UPPER(APTIBANK)+UPPER(APTICHECKN)+STR(APTIIMMED)],FOR[.NOT.DELETED()]')
APTIMEMO MEMO(10),NAME('APTIMEMO')
Record RECORD,PRE()
APTITRNUM REAL,NAME('APTITRNUM=N(5.0)')
APTIVENDOR STRING(20)
APTIINVOIC STRING(15)
APTICHECKN STRING(15)
APTIPONUM STRING(20)
APTIDES STRING(30)
APTIADDR1 STRING(35)
APTIADDR2 STRING(35)
APTIADDR3 STRING(35)
APTIADDR4 STRING(35)
APTIPAID REAL,NAME('APTIPAID=N(1.0)')
APTIIMMED REAL,NAME('APTIIMMED=N(1.0)')
APTIDUECTL REAL,NAME('APTIDUECTL=N(1.0)')
APTIDUEDAY REAL,NAME('APTIDUEDAY=N(3.0)')
APTIDISCTL REAL,NAME('APTIDISCTL=N(1.0)')
APTIDISDAY REAL,NAME('APTIDISDAY=N(3.0)')
APTIPLINES REAL,NAME('APTIPLINES=N(3.0)')
APTIRLINES REAL,NAME('APTIRLINES=N(3.0)')
APTILINES REAL,NAME('APTILINES=N(3.0)')
APTICHECK REAL,NAME('APTICHECK=N(1.0)')
APTISTATUS REAL,NAME('APTISTATUS=N(3.0)')
APTIINDATE DATE
APTIDUDATE DATE
APTIDSDATE DATE
APTICHDATE DATE
APTIGLDATE DATE
APTIDISC REAL,NAME('APTIDISC=N(17.4)')
APTICONV REAL,NAME('APTICONV=N(14.6)')
APTIPAMT REAL,NAME('APTIPAMT=N(15.2)')
APTIRAMT REAL,NAME('APTIRAMT=N(15.2)')
APTILAMT REAL,NAME('APTILAMT=N(15.2)')
APTIPETTY REAL,NAME('APTIPETTY=N(1.0)')
APTIFLAG REAL,NAME('APTIFLAG=N(1.0)')
APTIBANK STRING(3)
APTICASH STRING(30)
APTIRECUR STRING(6)
APTINAME STRING(35)
APTIDISCF REAL,NAME('APTIDISCF=N(1.0)')
APTIMEMO_PTR LONG,NAME('APTIMEMO')
APTICODE STRING(6)
APTIEFT REAL,NAME('APTIEFT=N(1.0)')
APTIEFTACT STRING(3)
END
END

Now that you mention that, I can see how the problem might occur even though my file declaration has keys in it.
The NAME attribute of the keys - I have discovered that the '___' at the end of the filenames (in key and data files) are substituted with the batch number in which these records are generated. For example, records in batch 'AAA' will be stored in file 'BFPAIAAA.dbf' and the keys will be stored in 'BFPAIAAA.mdx'. The file declaration states that the keys are located in 'BFPAI___.mdx' and even though this file might be updated, CMS will never know about this update unless it is done to 'BFPAIAAA.mdx'.

So, I think that the key also needs a path variable in it's NAME attribute, this must be primed before opening the file in order to update the right key file.

Am I right?
Keith