Does anyone now why I am not able to access the custom fields? Obviously the BPM is not complete, but I am just trying to see why I cannot have access to the special fields?
Your datamodel may not be in sync then. Try regenerating the datamodel.
This is an old field from years ago. And I double checked and datamodel is synced.
I have added two screenshots, on the first one as you can see it gives me an error not recognizing the custom field.
Try using the following methods to get/set UDFs when dealing with temp tables:
string projectName = orderHedRow.UDField<String>("SpecialProjectName_c");
Change the type if SpecialProjectName_c is not a string.
To set it…
orderHedRow.SetUDField<string>("SpecialProjectName_c", "New special project name");
2 Likes
Yes it worked! Thank you!!
But when you try, do you see the custom fields in a normal way without using brackets? Like orderhedRow.CustomFieldHere
We are using version 10.2.300.41.
Not in a method directive. Only Data Directives.
1 Like
Thanks again for your help!
When you add UD field and regen DB model, then only EF entities are extended. As a result, if you use a parameter table of data directive or properties of DB context entry (e.g. this.Db.Tip.Field) then real .NET property is available.
Method directives operate on tablesets. ERP does not change them, since there is no way to synchronize such changes between server and client. So, UD fields (and Extension Peer fields) are available only as an “extended” properties on table row.
To make access typed, BPM provides UDField and SetUDField extension methods for tableset rows mentioned in this thread…
I strictly not recommend to use this syntax. It does not check types. UDField and SetUDFiled methods should be used.
I suppose this is technically correct, but you could always force the type too. I’ve written hundreds if not thousands of BPMs like I showed without issues though.
Definitely, I cannot prevent you from doing that. I just explained how it was designed to be used… starting 10.0.
@SAD - Sorry if this question is something I should know, but aren’t you having to cast the type of the custom field when using the UDField method anyway. So casting the wrong type in either case will cause runtime errors? I’m just trying to work out the benefit since I’ve been using what was suggested by @Jason_Woods up until now.
1 Like
When a typed method is used, it checks that a value that your providing has a compatible type at design time. So it protects you from mistakes (e.g. you use a variable or another field with a wrong type or type of this variable/field has been changed after the moment when you created the directive).
In general. typed accessors minimize (not avoid) the possibility of miscasting.