Kevin,

I have verified the behavior in this thread, that the first call to the bizobj.save() sets the this.oExecutant property to the initalselectedalias cursor object. If a setalias('v_New_alias') is executed, and a new bizobj.save() is performed, the bizobj.getdataaccessObject() will not re-determine the new data access object if the this.oExecutant property already contains an cursor object.

The fix I made was to the SetAlias() method to also release() and set =null the this.oExecutant property. Everything works correctly with this patch.

Please put this fix into the next release of MM. If you have a better code solution would you please provide it so I can plug it into my current version.

Thanks,

Gary Pike.

>David,
>
>>I believe that there is an issue with the setalias() function of kbizobj. In particular, it does not update the oExecutant property with the business object. This only occurs if the oExecutant property changes. So if you call setalias() before the oExecutant property is initially set, you will NOT encounter the problem. If, however, you save to one view, then call setalias(), and try to save to another view, oExecutant does not get changed to the new cursor object, and therefore the wrong view is updated.
>>
>>I think that all that needs to be done is to add a line or two in the setalias() method that updates the oExecutant object.
>
>Are you using RemoteExecutantSave() in this scenario? I'm out of the office right now and just have a few minutes, but looking at the code for RemoteExecutantSave(), I see that it calls this.GetDataAccessObject() to determine which data access object to use. GetDataAccessObject() calls this.oDataEnvironment.GetCursorObject() with an empty tcAlias. GetCursorObject(), when passed an empty alias, gets the data environment's InitalSelectedAlias, which should have been set to the proper value when you call SetAlias().
>
>If you're still having problems, let me know where along this logic loop the problem seems to occur!
>
>Regards,