Is there a difference between SetParameter(int pid, string key, Object value) and SetParameterByPrimaryKey(int tablePid,string key,Object value) on the element object in the automation engine?
As when trying this, SetParameterByPrimaryKey works fine on the main element, but fails on the function DVE. However when using SetParameter, with the table key also specified, it worked as well on the function DVE.
I think the biggest difference is that the latter call (SetParameterByPrimaryKey) is trying to resolve the display key based on the primary key that you specify. The SetParameter method is using the display key as input (second argument). But I think regardless of this, it is doing the same call internally.
That might be the problem… By the way, are you using the flag ‘NoKeyCaching’ as this will also be taken into account?
You can verify the GetTableKeyMappings method by trying out the SLNet call GetDynamicTableIndices.
Just to verify what Jarno states:
I had a discussion a while ago about the SetParameterByPrimaryKey in which it was also stated that it uses the display key in the background.
This can give problems in situations where you have a table with duplicate display keys but unique primary keys. (it will randomly update one of the rows that has the same display key as the one for which you passed the primary key.)
I can confirm what was said is correct here the SetParameterByPrimaryKey is internally rerouted to the SetParameter method and is resolving the primary key to a display key through an internal cache that is populated through the GetDynamicTableIndices SLNet message.
Regarding duplicate display keys this is not supported and indeed triggers undefined behavior.
So just checked what happened when I did a .GetTableKeyMappings(int tablePid). In case of the main element it returned mappings, but in case of the function dve it returned nothing. Not sure if it might be related to that