OK, I just applied PU3 to my v2023 Standard and the error stopped.

Correction: PU3 did not help.

I’ll start out by saying that no, you most likely have no control over this.  It is definitely a severe bug that Sage needs to find a resolution to.  Most of our clients have a substantial number of scripts (some up to 200) running within their systems.

We started noticing error 88 over a year ago in the 2020 version when the server OS was updated from 2012.  At the time error 88 was a bit of an annoyance and we could never consistently reproduce it.

Since the update to 2023 (running on either Windows server 2019 or 2022), it has been more pronounced.  I would say at least a 20-fold increase in the number of reported instances and at present, we can reproduce the error pretty much at will, but have no way of resolving the problem since it’s a bug in Sage’s own code.

We also have tried the PU3 update, but to be fair, that fix addressed specifically an issue with the Messagebox method call, not a script executing on the business object itself, though our suspicions are that they are strongly related.  I have another post on this board describing that.

Our developers (both vbScripting Sage consultants and our MS C# development team) are pretty convinced it's a problem with how Sage's script host module is handling the COM enumeration when multiple objects are created in memory within a single UI session. 

In your case, and many of our client’s case as well, it’s pretty prevelent on the oLines property of the oBusObj.  These are treated as two separate objects in vbScript and we take care to set these = nothing when done with them.  Also, we ensure that every script now runs under a different priority level to avoid having multiple scripts that may use/dispose of a similar object in the same subroutine when compiled in to Sage.  I will say, we’ve yet to encounter it on the oHeaderObj of a line item oBusObj object.  Probably because we have far fewer of those calls in our scripts than the oLines one.

Our team has hundreds of hours troubleshooting this and have little hope that a resolution to this is on the near horizon.  We are working on a plan to abandon having Sage do any object handling within their script engine and offload those to a custom DLL where we can control the instantiation and disposal of these objects ourselves using C#.

To give you a deeper picture of what's actually happening when you get an error 88, next time it happens click the Info button on the error screen from your screenshot, then click the Debug button on the next screen to open the providex interpreter.

At the Ready> prompt, type:

? HandleVB'*

and press enter.  This will display the public properties and methods on what should be the MS script object Sage currently has in memory when the error is triggered.  Note that all of them are prefixed with Pvx indicating that this is a handle to an undefined providex object, not a MS Script host specific object.

Now, at the Ready> prompt type the following two lines to instantiate a new Microsoft Script host object within providex and display the public properties and methods on the new object.

def object o, "MSScriptControl.ScriptControl"

? o'*

Note that this object now has several other exposed properties and methods (AllowUI and Run() being by far the most used) indicating that the object o is now a valid MS script host handle is in memory.  

Depending on the line number reported by SY_Maint when you receive the error 88 determines which of these two items is missing from the object in memory.  For example, if the error is line 3556, it's an error 88 when attempting to reference the missing AllowUI property from the MS Script object.

In your particular instance, line 3455 is likely a table event and is trying to call the following method:

handleVB‘Run(tmpPROC$)

The Run() method is missing from the currently running handleVB object, resulting in Error 88.

You can find out what script is attempting to execute by typing this at the Ready> prompt:

? tmpPROC$

This will display the object script that is currently trying to execute.  In our case, it is always on the very first pre/post validation script attempting to execute on a field in the oLines object and always on the second attempted call while still in the same Sage UI session.

You'll also encounter them at line 3450 (validation script on a string field) and 3452 (validation script on a numeric field).

When done with these tests, enter:

bye

And press enter to exit the providex interpreter.

Hopefully, you and others will find this informative.  I’m happy to exchange ideas with anyone else who is facing these issues so we can help Sage come to a resolution on this. 

From our standpoint, we have many large, long-term clients that are losing their good humor with all of these problems.

Here's the link to the other Error 88 that I've comments that I've made:

(+) Community Hub (sage.com)

Thanks for the detailed reply!  It's nice to know it isn't just me / us. 

When I have time to dig into this more I will check on those debug commands, which are handy to be aware of for sure.  (We're not a Master Developer firm, so source code / line numbers are not something I can research directly).

Intermittent issues are indeed frustrating.  Sometimes I can move line script logic into a header pre-write script (avoiding that specific issue) but sometimes that is not possible.  In another project I am trying to move the button script logic into a column post-validate on a checkbox... which I am hoping will help (because problems seem to be more frequent when button scripts are involved).

Example of what I was hoping for:

retAllowed = oSession.AsObject(oSession.Security).IsMember("rolename")

The above command causes error 88's upon repeated use within the same data entry session... but the replacement command (below) works without that problem.

retAllowed = oSession.IsMember("rolename")

Obviously I have no visibility over such possibilities directly.

Sometimes trial-and-error leads me to add lines like "Set oMyObj = Nothing" to the end of button scripts, to help ensure objects are cleaned up properly, but those are just guesses.  How the scripts / objects are handled in memory is totally beyond my visibility.

Hi Kevin,
I am looking into this and will let you know what I find.
I won't be surprised if the issues that TPETERSON detailed for us are related.

Thank you.
Bret

Thanks Bret.  I appreciate that.

(I am hoping that having a nice simple example to reproduce the error will help the Sage engineering team's troubleshooting efforts).

Absolutely!

Let me know how I can assist with this.

Quick update... we are able to duplicate Kevin's issue using his SO Detail Pre-Write and Button scripts and are working on the fix. I will keep you posted.

Sounds good Bret.