I’m looking for a way to know which fields were modified by the user, for an extended “last modified by” function. The problem is that the table concerned contains about a hundred fields, which are presented on a number tabs on a form. The client wants to keep track on each of the tabs which user has made changes (different users are allowed to modify different sections). Due to the large number of fields, putting some code in each OnValidate trigger is not very attractive. The idea was to loop through the REC and xREC records in the OnModify trigger and compare the fields from both to know which are changed, but there appears to be no way of reading fieldcontents without specifying each field by its name. Using table 2000000041 Fields, you can get the fieldnumbers and fieldnames in the table to examine, but how to use these numbers/names to read the REC fields? FIELDNO and FIELDNAME functions don’t accept variables as field parameter (and doesn’t return a “field” type), nor does (of course?) the usual method of retrieving a field value. In the designer it is allowed to use Rec.“1” as syntax, but you can’t replace the “1” at runtime with something else? Suggestions, anybody? TIA John
John I did some work on a code unit to deal with this, but I had to pass rec & xrec to the codeunit then hard code every field I required. Then on modify call this codeunit to populate a second Table! I could replicate the Code for you if you are Interested Then you could create a codeunit which will go through the Fields table and write into a text document, which would then be pasted into your function! Mr David Cox MindSource (UK) Limited Navision Solutions Partner Email: david@mindsource.co.uk Web: www.mindsource.co.uk
David, Hardcoding the fields is exactly what we tried to avoid. Further asking around and doing our own experiments learned that it is simply not possible (yet) to address fields without supplying the fieldnames hardcoded. Well, one of our programmers will have a boring day, I’m afraid, but we will have to put in some tedious Case Of routines. Pity (and against our attitude of lean-and-mean programming), but the project is on a too tight schedule to allow more (re)searching. Thanks anyway. John
To access (read and write) contents of a field by record and field number - another feature to add to our wishlist.
Could you make use of the Cfront.OCX in some way?
Write Rec and xRec to a file with Write(FORMAT(Rec)) or something similar. Then you find what fields are in the table by looking at the Fields table. By comparing Rec and xRec from the file you can see which fields have been modified. You can even create field level logging & access control by this method. I don’t think that you can use the C/FRONT to do this. Sure, you have dynamic access to the fields of the record but there is no such thing as xRec in the C/FRONT. - regards, Dadi Dadi Karason dadi@naviplus.com
Thanks for all your co-thinking. For now we chose the solution to use a long list of Case Of statements to keep track of “Last changed by” per tab (section). To get history logging, we took the brute way: write the full Rec and xRec to another table. By comparing these entries, you can see the changes. Elegant? No. Workable? Yes. Grtz John
… and one nice day you will add a new field to the table … 
This would be fine if we were talking Record Replication but John wanted to only record which fields had change from what to what, not which records have changed!!! Fabian Wrote: … and one nice day you will add a new field to the table … Mr David Cox MindSource (UK) Limited Navision Solutions Partner Email: david@mindsource.co.uk Web: www.mindsource.co.uk
Sure, David, but he would have to include this new field into the Mega Case-statement to track the changes. And I bet one monthly salary that most likely he will forget about. (At least I would)
Yes, Fabian, this “maintenance nightmare” is exactly the reason why we wanted to loop through fields. When you know that it’s not only needed for tracking the changes, but also to set the editable property of the textboxes on the form depending on the permissions of the user that logged in (user A may edit textbox 1 and 2, but user B only textbox 2), you can understand why we would have loved to approach the table fields as an collection (C++ and VB programmers will understand what I mean). For now, we have to live with having strict instructions for adding fields to this table. John