jepritchRed alert! Yikes! UDS's have had great forward compatibility. I hope that hasn't changed with 2021.1.

I have also had a couple scripts across multiple clients that worked fine on prior versions all of a sudden produce errors after upgrading to either 2020 or 2021.  Had to add additional filters to restrict them.  Will have to review all the details, at the time, I just chalked it up to things changing.  I think for the most part, most scripts function fine but if you are doing anything really in depth or complicated, there is a chance something might break between versions.

FYI, i've seen hard errors caused by GetChildHandle if the field used is empty OR if the data source does not yet exist in the string returned by the GetDataSources() method.  So you should check if both the field used for the data source is not blank and that the data source exists in the string returned by the GetDataSources() method.

Kevin M - I don't think we changed anything with the scripting itself, and possibly more than likely changes to the underlying code (as you stated) has moved some logic that could have scripting attachments that now fire differently.   Is it isolated to one of SO_Invoice_bus/SO_SalesOrder_bus or does it seem to be more wide spread than that?

E

The issues I dealt with this week are both limited to an SO_InvoiceHeader script, where it seems the script is triggering far before it should.  Perhaps David has other examples.

The core script logic seems fine.  It's the event triggers.  From what I saw, Column Post Validate on header fields are triggering extra early, in ways that are different than v2019.  During troubleshooting I added a pop-up message for one script, and it actually seemed to run twice, which in this case is fine because it's not doing anything where duplication is a problem, but I could see that being a potential issue at some point for certain types of scripts.

The startling example is not being able to open SO Invoice Entry and choose a batch, because the script fires / fails.  (To be clear, it compiled fine with no error in UDS maintenance...).  Filtering based on blank InvoiceNo / CustomerNo removed the error because the filter stopped the problematic run of the script, with the second iteration of the script trigger applying the required business logic as it used to.

Nice workaround Kevin! 

Filters can be your friend.

The other thing that may work as well is making your script conditional on oBusObj.EditState<>0, since this is firing before any key is set.  This is a good general practice, although this has worked in previous versions.  

I believe I have found the issue as it relates specifically to SO_Invoice_bus but I need to do a little more research.

Speaking of EditState, what is the best way to check if using a *_Svc class since the property only existing when inherited from the SY_Maint class?  Do you just need to loop through the key columns using GetValue and see if they are blank or have I missed a better way to do that?

Reason I ask is because even after using Clear, GetKey still returns the last key used.

With service objects, the intention would be to use them then check values generally.  There isn't a similar property for the service objects, this is true.

Thanks for the tip!   I'll try this next time.

oBusObj.EditState<>0