Closed fvet closed 5 years ago
Please upvote on Experience Ideas https://experience.dynamics.com/ideas/idea/?ideaid=0e3cebdf-d36f-e911-80e7-0003ff68bfb9
One scenario that needs to be excluded is the Record.GET(Some_Var_Of_Type_RecordId)
@fvet thank you for posting this on the Ideas site as well. I will close this issue so that we can focus our attention in one place. For anybody interested in seeing this feature implemented, please vote on the idea.
One scenario that needs to be excluded is the Record.GET(Some_Var_Of_Type_RecordId)
This also needs to be documented... It is not at all: Record.Get([Any,...]) Method
The closest hint is this:
You cannot use the Get method to retrieve a record in a table by its primary key value if the primary key field in the table has the data type RecordID. In this case, you can retrieve the record by using the SetRange Method.
But it doesn't explain why one can't do that, namely because Get(RecordId)
is overloaded to mean 'get the record whose PK forms this RecordId', not the expected 'get the record whose PK is a single field consisting of this RecordId'.
Good job I am having a quiet day, off to file at least one issue on https://github.com/MicrosoftDocs/dynamics365smb-docs/issues ... edit: actually, it's https://github.com/MicrosoftDocs/dynamics365smb-devitpro-pb/issues
Is your feature request related to a problem? Please describe. In some scenario's, primary key definition might be changed (by adding / removing fields), resulting in review of code that fetches the record using the GET statement.
Describe the solution you'd like I would be interesting to have a CodeCop rule that warns (not errors) about GET statement where the number of arguments does not match the number of fields included in the primary key of the table referenced.