IndexSeek and Buffering Problem

[SGLong]

I'm running into a problem with a buffered table and a candidate index. At several points in my code I need to know if a table entry exists, so I use the indexseek function. If it does, then I 'replace' the values. If it doesn't then I insert a new record. That worked fine until I activated buffering for the table. I need to be able to TABLEREVERT if any error conditions occur during processing and TABLEUPDATE if there are no errors detected. Now when I indexseek I get a 'uniqueness of index batreqnum has been violated' error. Why would buffering cause such a problem and is there a way to handle it without generating an error?

Steve

 

[danceman]

in using indexseek the second parameter to this function is .t. if you want the record pointer to move if the record is found. set to .f. if you do not want the pointer to move. this might help

the other thing I noticed is your reference to replaceing value if exist. the value you are replacing, is it the index field? that could be a problem if it is.

hope I helped jog some ideas. Attitude is Everything

 

[SGLong]

My indexseek line is as follows:
INDEXSEEK(gcBatchNo,.T.,"PetePlanFile","BatchNo&quot
It is this line that is generating the "uniqueness of batreqnum is violated" error. Batreqnum is another index tag in this table. I'm not replacing any of the key values - just some date/time stamps, but I don't even get a chance to do the replace because of this error.

I'm puzzled by the fact that an indexseek on one tag is violating the uniqueness of another tag.

 

[chpicker]

I assume you are using row buffering, not table buffering. Because of this, VFP tries to write any changes you've made to disk as soon as you move the record pointer.

There isn't any way to tell if any errors occur BEFORE you issue TableUpdate(). However, TableUpdate() itself won't generate an error; instead it returns .F. if an error occurred. You can then use AERROR() to find out what went wrong (Uniqueness, Trigger failure, etc) and TableRevert() if necessary.

Hope that helps,

Ian

 

[SGLong]

Actually, I'm using optimistic table buffering. Maybe that's part of my problem. The index tag BATCHNO is a normal index on a single field - cBatchNo, while the BATREQNUM is a candidate tag based upon three fields - cBatchNo + cReqNo + cNumVal. When the table is opened the master index tag is BATREQNUM, so when I do an indexseek on the BATCHNO tag maybe the fact that there are multiple records with the same value for cBatchNo the BATREQNUM tag is choking. Does that make sense?

 

[danceman]

it does sound like that may be part of the problem.

the .t. in your indexseek means to move to the record found. Attitude is Everything