A question to understand how the system works: what happens, if i change a field of a table which is part of filtering ? example: I have a table, where i’m looking for a blank field. If i find one i change the contents of this field: Customer.SETRANGE(“No.”, 1000, 1200); IF Customer.FIND(’-’) REPEAT __PurchaseOrder.SETRANGE(Customer, Customer.“No.”); __PurchaseOrder.SETRANGE(PurchaseDate, 0D); __IF PurchaseOrder.FIND(’-’) THEN REPEAT ____PurchaseOrder.PurchaseDate := TODAY; ____PurchaseOrder.MODIFY(TRUE); __UNTIL PurchaseOrder.NEXT = 0; UNTIL Customer.NEXT = 0; don’t wonder about the sense of this. It’s just an example. But - does the system has a problem with this, because i update a field which is filtered (field “PurchaseDate” of table “PurchaseOrder”)? Does this have affect to the filtering ?
Yes, BIG problems, but there is an easy solution for it. I did have the same problem. You can create a variable recpurchase record PurchaseOrder You can change your code like this just an example IF PurchaseOrder.FIND(’-’) THEN REPEAT recpurchase := PurchaseOrder recpurchase.PurchaseDate := TODAY; recpurchase.MODIFY(TRUE); No problem with the filter anymore![:D]
i wondered why only part of records have been changed and i guessed there was a problem doing it my way. I’ll change the code as you said and will check the result. thanks so far, DAD [:)]
hi I also faced the same problem with dad, and sorted it out as DAD did harikesh
Try this code Customer.SETRANGE(“No.”, 1000, 1200); IF Customer.FIND(’-’) THEN REPEAT __PurchaseOrder.SETRANGE(Customer, Customer.“No.”); __PurchaseOrder.SETRANGE(PurchaseDate, 0D); __IF PurchaseOrder.FIND(’-’) THEN ____PurchaseOrder.MODIFYALL(PurchaseOrder.PurchaseDate,TODAY); UNTIL Customer.NEXT = 0;
Stefan - your code should not cause any problems. However, it depends on the key in use: If your CURRENTKEY=“Customer,PurchaseDate”, you will find the first record with PurchaseDate=0D; you fill in a date in the record found, modify the record - and now you have moved your pointer. That is why you must copy your record found into another instance of that table (e.g. rePurchaseOrdrer) and make your modification in this second instance. Do not change a field if it is within the current key.
As Anfinnur said it’s only creating errors when changing a field which is also an part of the key. But in those cases where you changing an field that you have filtered and also have in the key you could use the following piece of code: table1.setcurrentkey(filtervalue); table1.setrange(field1, FilterValue). while table1.find(’-’) do begin table1.field1 := SomeOtherValue; table1.modify; end; Just as an little compliment to the other answers. /Daniel
thanks to all the changed field was not part ot the current used key. Nevertheless the system only found (and amended) the first found record of the customer. After having changed the code as DAD said it worked fine. Due to what Daniel and Anfinnur said my original code should have worked fine, but it didn’t. Could this be a bug of our version (DE2.50) ? to Daniel: your last example has the part “WHILE table1.FIND(’-’) DO BEGIN…” I haven’t tested it yet. But is the record pointer set by the “WHILE”-command ? I thought it was only set by the “NEXT”-command [?][?] Does this solution has an advantage (speed) in comparison to REPEAT… UNTIL NEXT [?]
The field that changed, was that part of the Primary key? Because then it’s attached to any key that you are using. Otherwise, to my knowledge your code should be ok. In the While statement you don’t need a NEXT statement. The pointer is set by While as you say. As far as I know there are no difference between Repeat-Until or While, just another to way to do the same thing. Best Daniel
Hi Stefan, The Problem is that if you change a field which belongs to your filter, the record no longer belongs to this quantity of records and the pointer jumps to another record of the filtered records. But it is coincidence where the poiter stands after this, for example the last record. So your code can miss some or nearly all records or only finds the first. With the While-loop you don’t miss any records, because after changing the field the pointer searches for another record of the filtered quantity unitl no record exists. Nevertheless i prefer the same way as DAD. Hope this helps. Greetings, Frank