Last time I commented on how the unsuspecting developer has no way of knowing what is going to happen when they use this command due to the way it copies fields between tables using the field ID to map the tables. Since then I have been tripped up again by this evil function and instead of simply moaning about it, I thought I would suggest an alternative.
So here I am going to introduce the all-new transferfields functionality. Microsoft, please feel free to take this idea and implement it in NAV.
The TRANSFERFIELDS command is programmed the same as now but in order to use it, a field mapping between the two tables must be defined at the table definition level. Let’s say we want to transfer fields from the Purchase Header table and the Purch. Inv. Header tables. You can find an example of this in the Purch.-Post codeunit as follows:
PurchInvHeader.TRANSFERFIELDS(PurchHeader);
This line takes the fields from the PurchHeader record variable and transfers the fields to the fields with the same field ID in the PurchInvHeader record variable.
If you have not defined a filed mapping between these two tables, the above code will not compile. In order to define the mapping I see it working like this.
Go to edit the Purchase Header table and select View menu and select the Table Mappings option. This will launch a form similar to the following:
On this form, you can insert a new line and enter the To Table ID to identify the table you want to map to. It would probably make sense at this stage for the system to automatically insert mapping between the two tables based upon the matching field IDs of the two tables. In this respect replicating the existing behavior would be pretty easy.
To customize the field mappings for the tables, the user will simply click the assist edit button on the Mapped Fields field and this will show the Field Mapping form.
Here the user can set up the field mapping. There are a couple of great things about this approach, you can ignore fields that you would never want to copy, such as the No. field. You can also map fields with different IDs. The other great thing is that field mappings can be managed by end users without the need to write code. An example would be if the user creates a new custom field on the Purch. Inv. Header table called Original Purchase Order No. The user can then make sure that the purchase order number ends up in this field by just using the mappings.
We could even add some rules on what to do when the fields don’t match in type, i.e. should we truncate the string or throw a run-time error.
6 comments:
Hm, nice idea, it would really make TRANSFERFIELDS more predictable, and manageable. However I don't think this will get implemented any time soon - when you take a look at how pages and forms are mapped, an even weaker intrinsic mapping is used.
Very very nice idea! You should tell Microsoft how to do it!
An alternative is to create a codeunit like the Transfer Custom Fields codeunit 10201. Then you can specify any two tables you want and end users with a designer license could have access to it as well.
nice idea, it would really make TRANSFERFIELDS more predictable, and manageable. However I don't think this will get implemented any time soon - when you take a look at how pages and forms are mapped, an even weaker intrinsic mapping is used.
What you describe is more or less how the good old character based NAV worked.
There you could set up a transfer list where you first defined from which table to which table to transfer and second which fields from table A to transfer into fields from table B.
The transferfields function did have a parameter with which you could choose to use the transfer list (false) or to copy all fields (true).
As this function was dropped with the first windows version of NAV I think it is safe to say that we will never get this function back.
That's really intersting to learn about how things used to work. I think it's a real shame they dropped it. I've learnt to live with the TransferFields function and have even grown to like it in a way - like anything else it's just frustrating when it goes wrong and takes a long time to track down the cause.
Post a Comment