Hi all, Just found out with the help of Jan van Puyenbroeck, That if you call a onmodify trigger from a codeunit, the rec and xrec variables are the same. I classify this as a serious bug in NF, And would like to have it fixed in the near future. Best regards,
I don’t consider this behaviour as a bug. Question: When - if not after saving a modified record - should xRec become Rec? ------- With best regards from Switzerland Marcus Fabian
Hi Marcus, Let me clarify, A function, (Or trigger in this case) should perform consistently in any situation. In a function predefined variables should also contain consistent data. In this case there are 2 different situations. 1 When an OnModify trigger of a table is called when somebody is altering a value in a table, xrec points to the previous record, and rec to the new or current record. (This is the documented behaviour) 2 When an onModify trigger of a table is called from a codeunit This suddenly doesn’t hold true anymore and xrec and rec both point to the same date. (The current record). So in these cases a function doesn’t perform consistently, So i cannot rely on xrec pointing to the previous record because depending on how the onModify trigger is called xrec does or does not point to the previous record. Also there is no way to determine in the onModify trigger if this trigger was called automatically by the system (Due to alteration of table data) or explicitly by a codeunit calling the MODIFY(TRUE) function. because then i at least could know if xrec was pointing to the previous or current record. I know of at least 1 situation in which navision isn’t aware of this bug and made a serious programming error in one of their products. Again let me clarify. The navision webshop uses a SQL database where a subset of the data in the NF database is stored. for example only about 5 fields (to lazy to count them exactly ) of an item is stored on the SQL database, whenever item information is changed (Like price or description) this information is updated. They way it works is as follows. On the onModify trigger Navision programmed a function which checks if the 5 fields which are stored on the SQL database are modified. If yes then the record on the SQL database is updated. So for example if you change the price of an item, the item is updated on the SQL database (And the customer on the website can see the new price). The function is pretty straightforward and very oversimplified looks something like this IF rec.description<>xrec.description then bUpdateSQL=TRUE; IF rec.Price<>xrec.Price then bUpdateSQL=TRUE; IF rec.Code<>xrec.Code then bUpdateSQL=TRUE; Now lets suppose we need to alter the price on a specific item type and we used a codeunit to do it. using the following code: item.reset item.setrange(type,“NUCLEAR POWERED CYCLES”) if item.FIND(’-’) then REPEAT item.price:=item.price*6; (I know the price raise is significant. But his black market source for Uranium 235 has dried up ) item.modify(TRUE); UNTIL item.NEXT=0 In this instance the onModify trigger fails to pick up the change in price (Due to xrec and rec being the same), and fails to update the items on the Web SQL Database. So the customer on the website still sees the old price. This means you have inconsistent data in your SQL database. This not only holds true for items, but also for customer information, shipping addresses. invoice address and loads more, in short for any information stored on the WEB SQL machine. So due to this bug you can never be sure if all data on the WEB SQL database is consistent with information in your NF database. The way to work around this is to NOT use the method of comparing xrec and rec and always update the WEB SQL database. But for people who know the Webshop this can be VERY undesirable and could invoke massive updates to the WEB SQL database even when these updates are not necessary. (Just think of updating 150.000 items ) And to answer your question marcus. xrec should be the same after you saved the record. But the onModify trigger is called BEFORE a record is saved so xrec should still point to the previous record. Best regards, Mario van Zeist
Actually, I think this is intended behaviour. xRec holds the record as it were before any changes, but it is on a per instance-of-an-object basis. From what I can see in your description, you expect xRec to work across objects, and I am 100% sure that that is not intended xRec behaviour. Lars Strøm Valsted Head of Project and Analysis Columbus IT Partner A/S www.columbusitpartner.com
Mario, this behaviour is well documented in the C/SIDE online help. Have a look at Contents in C/SIDE Reference Guide → Information → xRec and FIELDNO Torsten