Another user has modified error

nazunazu Member Posts: 70
hi Expersts,

I have a requirement:-
on valiadte of BOM schedule qty on job task i populate a customised field.
If teh value in the field goes -ve i pass a positi8ve entry to make it zero(client requirment).
I have annother field on job task as task blocked.So when my customized field value goes 0 i need to make task block=true.

However i get error as "another user has modified the record.
I decalred as same valriable as that of rec coz using rec it used to ask me for renaming of record.wat i did was
recjobtask.setrange(jobno,currentjobno);
if recjobtask.findset then
repeat
recjbtask.calcfiledls(customizedfield);
if recjobtask.customizdfield=0 then
recjobtask.taskblock=true;
recjobtask.modify; //i know this modfiy is causing this error...bt how to resolve?
until recjobtask.next=0;

Please help me

Comments

  • SogSog Member Posts: 1,023
    FYI I don't know why you are looping those records.

    No error code (I think):
    recjobtask.setrange(jobno,currentjobno);
    if recjobtask.findset then
    repeat
    recjbtask.calcfiledls(customizedfield);
    if recjobtask.customizdfield=0 then
    begin
    recjobtask.taskblock=true;
    if rec = recjobtask then
    taskblock := true
    else

    recjobtask.modify;
    end
    until recjobtask.next=0;

    The REASON why you have this error is because the current record you just modified is in the recordset of recjobtask.
    So you modify the record and the loop modifies the record (which is a different variable). And because of that you get the error.
    Also, you were modifying every record wether or not it had to be modified.
    |Pressing F1 is so much faster than opening your browser|
    |To-Increase|
  • nazunazu Member Posts: 70
    Hi Sog,

    thanks for the reply.

    See whne i add a quantity in BOM scheduke qty....my cutzomized field beocmes zero.(based on some calcluations).
    Now since my customized field becomes 0..i want to block all the job task lines so that the user doesnt enter a new quantity as the task is blocked.
    So i m looping thru the records to blcok all teh lines.

    i didnt get this line of code?
    if rec = recjobtask then(here recjobtask is same as rec) so waht difference it makes?
    taskblock := true
    else
    recjobtask.modify;
    end
  • vaprogvaprog Member Posts: 1,139
    nazu wrote:
    i didnt get this line of code?
    if rec = recjobtask then(here recjobtask is same as rec) so waht difference it makes?
    taskblock := true
    else
    recjobtask.modify;
    end
    Well, then you did not understand nazu's Answer ( and the root of your problem) at all

    What you are doing is similar to what happens in the following code.
    R1 and R2 are Records of the same subtype.
    In the following to alter a record means to assign some value to a field of a Record, to modify a record means to execute the MODIFY statement on that record.
    R1.GET('Key'); // reads Version x of the record
    // ... do anything with R1, possibly changing some field values in memory
    R2.GET('Key'); // this gets another instance of the same row buffered in R1 (Version x)
    R2.Field_n := 'SomeValue';
    R2.MODIFY; // creates Version x+1
    // ... more code, possibly changing some field values of R1 in memory
    R1.MODIFY; // ! You try to modify the Record based on a Version (x) that is older than the one currently in the Database (x+1)
    

    The R1.MODIFY; might be executed by the system, not explicitly stated in code for instance when R1 is Rec on a form.

    The code subset quoted above from nazu has one major problem though. It compares the Rec variables. But what does get compared by doing so? each field? some metadata (like filters, currentkey ...)? any memory structures which may contain uninitialized data or in-memory pointers? ... We don't know! And what if you altered some field of Rec before the loop?
    What it really should determine is whether the two record variables use the same row in the database, or in other words, whether the primary key of the two are identical.
    Therefore I suggest you do a MODIFY before the loop (if Rec was altered) and a FIND('=') and possibly a CurrForm.UPDATE(TRUE) if on a Form after it. But you need to check whether this is possible without breaking the logic of the hole code.
    The MODIFY (or SAVERECORD if in a form) is there so alterations on Rec before the loop do not get lost and are read within the loop. The FIND('=') updates Rec to the latest version of itself and CurrForm.UPDATE(TRUE) makes the form properly reflect all the changes.
    If it is not possible to save Rec before the loop you are stuck with nazu's approach, but comparing the primary key only, not the whole record.
Sign In or Register to comment.