Strange behaviour of TQuery.Next when updating

[FrankThynne]

I'm using TQuery with a local Paradox table. The query's SQL selects on a number of conditions including

... and DateProcessed is Null

The query is a live data set and I am updating it directly (not using cached updates).

The program steps through the rows found and, after processing the data, updates DateProcessed.

The code looks like this

with Query do
begin
First;
while not EOF do
begin
ProcessData();
Edit;
FieldValues['DateProcessed'] := SomeDate;
Next;
end;
end;

Clearly, when the Next statement is executed, the change is posted and the current row becomes invalid (because it no longer satisfies the query criteria).

However, at this point it seems that the next row is skipped, with the effect that only half the rows are processed.

I believe this to be an error in the BDE. At the moment I haven't devised a work-around. I've tried using filters instead, and I've tried using a Post statement before the Next, and the results are the same.

 

[svanels]

Is ProcessData another query/procedure that runs on the same dataset? Try to put all the conditions in the query, and use only edit and next. Somehow you are refiring the query. Steven van Els
SAvanEls@cq-link.sr

 

[Svanhooft]

hi,

If your data doesn't statisficy the query or the filter it will be deleted from the result set. The solution is simple donn't use the next statement. If you update a record, the row ia affected immediatily. So the next will not skip to the next record but the next+1. In a record set of 3 the first record is removed( we were updating that one) The second record will be the active one and then the next is performed. The second is skipped and the third becomes the active one.

steph [Bigglasses]

 

[EricDraven]

You should replace the next with a post and that should solve your problem. Arte Et Labore

 

[FrankThynne]

Hi Steven and Steph,
Once again you have responded to my problem, and thank you, and thank you Eric, too.

Steven - no, I'm not doing anything else that could refresh the dataset. Even if I were, experience shows that I would have been repositioned at the start of the dataset (after updating) and that isn't happening. I can repeat the problem in a test program when the only actions are writeln of data fields in the same sequence of code as the updates.

Steph - I agree with your diagnosis, and that's the problem. You'll notice that there isn't a a call to the Post method (there was at one time, but that's history), and that I rely on the Next method call to make the update happen. However, at the time the Next call is made, the update hasn't happened, so there's no reason for the BDE to execute another Next after updating the data.

I believe the dataset cursor processing is wrong. When the update happens, I accept that the (previously) current row is no longer valid. However, correct cursor processing should leave the cursor between the previous and next rows so that a Next call would find the one I expect - not the one after. This seems to me to a really serious Delphi or BDE bug.

Eric - what you suggest does, I think, work. However, it shouldn't. Executing a Post that removes a row from the dataset should leave the cursor invalid, and any attempt to access the data again without repositioning the cursor should produce an exception. I think it's part of the Delphi/DBE bug that it doesn't.

Finally, the work-round:
1. Make sure the query is unidirectional and not live.
2. Use another query to carry out the updates.

Are there any other bits of Delphi/BDE that are broken and I shouldn't use?