Using the tables on the file attached, could you test and give opinion on these examples
First setup Change Log for the tables and all fields
Testing OnRename Trigger
Open Table Test_1
Insert record with values: KeyField = 1, DataField = ‘A’ (press TAB to insert the record)
Go to the record and move to field DataField
Modify record typing as follows: Data = ‘AAAA’ (press Shift+TAB), Key = 100 (press TAB and select Yes to rename the record)
You will get the message on the trigger as follows
xRec: 1 AAAA
Rec: 100 AAAA
NOTES
xRec must say 1 A instead on 1 AAA
If you have a look on Table 405 Chanhge Log Entry you will see it saves the right values
You can try this on table Test_2 as follows
with no filters at all (it works OK)
with a fixed filter (not range nor expression) in one of the KeyFields (the same result as in table Test_1 when you change the KeyField with no filter)
Testing DELETE (F4)
Open table Test_2
Insert record with values: KeyField_1 = 1, KeyField_2 = 1, DataField = ‘A’
Insert record with values: KeyField_1 = 2, KeyField_2 = 1, DataField = ‘B’ (press TAB to insert the record)
Go to second record
Type in KeyField_1: 1, press F4 and select Yes to delete the record
The record that remains in the DataBase is 2,1,B
If you have a look on Table 405 Chanhge Log Entry you will see it saves as deleted the record 1, 1, B (never saved to the DataBase)
One more question on this, when writing code in OnDelete trigger, should we use Rec or xRec when testing values to allow deletion?
Pretty interesting tests. I didn’t know that the content of xRec was dependent of the trigger.
To answer you question, you should rec on the OnDelete trigger as it is the primary keys from rec that is used to delete the record and not primary keys xRec (the record you actually changed).
About your answer, if you use Rec to validate that the record can be deleted, if you changed the fields on the primary key, you are not testing with the right Data.
Let’s say,
Record 1: KeyField_1= 1, KeyField_2=1, DataField=A
Record 2: KeyField_1=2, KeyField_2=1, DataField=B
Record OnDelete Trigger: IF DataField=‘A’ Error(‘Cannot delete’)
Try the following,
Try to delete record 1 using F4 and you will get the error from the trigger.
Change record 2: KeyField_1=1 and press F4 and deletes the record with Key (1,1) that cannot be deleted if you look the trigger.
In my opinion xRec is wrong in the OnRename trigger (and also validate triggers – you get a similarly result), however xRec has the correct values in the OnModify trigger.
xRec on the OnValidate is ok, you have the records that your are modifying,
xRec has your modifications up to before the field you are validating
Rec includes all your changes, including the field you are validating
This is different in OnModify, OnDelete, xRec is the original record you read, and Rec includes all your changes, and this is what I think you must get on the OnRename trigger (an it really is, except in the case I was testing).
I was assuming you wanted to test the record based on the primary key fields. I guess your test shows that you need to re-get the record on the OnDelete trigger to perform test on non-primary key fields or check that the primary key fields haven’t been changed. I find this behavior a bit odd and I think we can agree that this is a bug in Navision.
I guess it can be discussed if xRec is wrong or not in the OnValidate triggers. I just find it a bid odd that xRec is different dependent on the trigger (change two non-primary fields and compare xRec between the last changed field and the OnModify – different, why?).
Anyway as long as you know how it works, you can program around it.
Definitely the values of xRec int he OnRename trigger do not seem to be what you would expect. Especially when you consider that they are differnt depending on weather you call the trigger in code (MyRecord.RENAME(TRUE) or by manually entering somethign in the field. I was recently in asituation where renaming the primary key in one record required renaming another record, and the code worked differntly depending on where the user triggered the code.
I worked around it, and it works fine, but I do think it is at least “An Undocumented Feature”, if not maybe a bug.
or by manually entering somethign in the field. I was recently in asituation where renaming the primary key in one record required renaming another record, and the code worked differntly depending on where the user triggered the code.