Sage 100

Is there a role permission check?  If you use the originally documented command for that, occasional error 88's do happen. (Alnoor can explain it better than I can).

isMember = oSession.AsObject(oSession.Security).IsMember(RoleName)

This (below) is the new command, which stops those errors

retAllowed = oSession.IsMember(sRoleName)

No role permissions check in the script.  The script writes order info to another SQL database only if the ordertype = S., but we have even gotten this error on quotes, where it checks the ordertype and then skips right to an invoke button call at the end of the script...

Is there a role permission check?  If you use the originally documented command for that, occasional error 88's do happen. (Alnoor can explain it better than I can).

isMember = oSession.AsObject(oSession.Security).IsMember(RoleName)

This (below) is the new command, which stops those errors

retAllowed = oSession.IsMember(sRoleName)

Does the button do things that cause other scripts to run?  There was an issue a couple years ago about error 88's with event scripts triggered by a button script... but that should be fixed in v2025.

No role permissions check in the script.  The script writes order info to another SQL database only if the ordertype = S., but we have even gotten this error on quotes, where it checks the ordertype and then skips right to an invoke button call at the end of the script...

Is there a role permission check?  If you use the originally documented command for that, occasional error 88's do happen. (Alnoor can explain it better than I can).

isMember = oSession.AsObject(oSession.Security).IsMember(RoleName)

This (below) is the new command, which stops those errors

retAllowed = oSession.IsMember(sRoleName)

Lee - Last week I responded to @Phil McIntosh about this. I'm assuming this is the same client for you guys. @Kevin Moyes and I mentioned there this could be another variation of the 64-bit script timeout issue but Phil mentioned this was a 32-bit system, so it wasn't that. I told Phil it could be something else and I would post a sample script soon to detect that. I will try to do so by this evening.

You may remember that in pvx, every screen only gets a max 32MB of workspace memory despite the amount of system memory present. Sage object code does a good job of DROP OBJECT and other things for memory management / garbage collection so that number never gets close to 0. However, with mods and scripts, we have to do the same thing, otherwise at some point in the day, that S/O Entry screen that's been working fine will potentially crash in some way.

** So a PostRead script can be created to show the available workspace memory based on the pvx DSZ system variable and placed in a UDF. I'll post that sample soon. The point here is when they report the Error 88 now you can now check to see if they are out of memory. 

@Alnoor - Is it possible that users having multiple Sales Order Entry screens open at once could contribute, or does each screen each get a full 32mb?

Lee - Last week I responded to @Phil McIntosh about this. I'm assuming this is the same client for you guys. @Kevin Moyes and I mentioned there this could be another variation of the 64-bit script timeout issue but Phil mentioned this was a 32-bit system, so it wasn't that. I told Phil it could be something else and I would post a sample script soon to detect that. I will try to do so by this evening.

You may remember that in pvx, every screen only gets a max 32MB of workspace memory despite the amount of system memory present. Sage object code does a good job of DROP OBJECT and other things for memory management / garbage collection so that number never gets close to 0. However, with mods and scripts, we have to do the same thing, otherwise at some point in the day, that S/O Entry screen that's been working fine will potentially crash in some way.

** So a PostRead script can be created to show the available workspace memory based on the pvx DSZ system variable and placed in a UDF. I'll post that sample soon. The point here is when they report the Error 88 now you can now check to see if they are out of memory. 

No each screen gets 32MB. OK here is how to figure out available workspace memory. Even if this is not the cause of the Error 88 at least this possibility will have been eliminated.

'Get available workspace memory. 'Either create a new Customizer button with no desc OR create a numeric UDF'Create a PostRead script and attach this to itrV =oScript.DebugPrint("About to get DSZ")rV = oScript.Execute("tmpDSZ = DSZ")vbDSZ = oScript.Evaluate("tmpDSZ")vbDSZFormatted = FormatNumber(vbDSZ,0,,,-1)'Now either set the button text OR SetValue into the UDF'retVal = oBusObj.SetValue("UDF_DSZ", vbDSZ)'Change BT_LINK_3 to whatever it is for youoUIObj.SetControlProperty "BT_LINK_3", "Visible", 1oUIObj.SetControlProperty "BT_LINK_3", "Text$", "Mem=" & CStr(vbDSZFormatted)

@Alnoor - Is it possible that users having multiple Sales Order Entry screens open at once could contribute, or does each screen each get a full 32mb?

Lee - Last week I responded to @Phil McIntosh about this. I'm assuming this is the same client for you guys. @Kevin Moyes and I mentioned there this could be another variation of the 64-bit script timeout issue but Phil mentioned this was a 32-bit system, so it wasn't that. I told Phil it could be something else and I would post a sample script soon to detect that. I will try to do so by this evening.

You may remember that in pvx, every screen only gets a max 32MB of workspace memory despite the amount of system memory present. Sage object code does a good job of DROP OBJECT and other things for memory management / garbage collection so that number never gets close to 0. However, with mods and scripts, we have to do the same thing, otherwise at some point in the day, that S/O Entry screen that's been working fine will potentially crash in some way.

** So a PostRead script can be created to show the available workspace memory based on the pvx DSZ system variable and placed in a UDF. I'll post that sample soon. The point here is when they report the Error 88 now you can now check to see if they are out of memory. 

@Alnoor Cassim,  I put this on a Sales Order Header Post Read event and it gives an Error 88 Object required:  
oUIObj, SY_MAINT.PVC 3480 in CallScript 

No each screen gets 32MB. OK here is how to figure out available workspace memory. Even if this is not the cause of the Error 88 at least this possibility will have been eliminated.

'Get available workspace memory. 'Either create a new Customizer button with no desc OR create a numeric UDF'Create a PostRead script and attach this to itrV =oScript.DebugPrint("About to get DSZ")rV = oScript.Execute("tmpDSZ = DSZ")vbDSZ = oScript.Evaluate("tmpDSZ")vbDSZFormatted = FormatNumber(vbDSZ,0,,,-1)'Now either set the button text OR SetValue into the UDF'retVal = oBusObj.SetValue("UDF_DSZ", vbDSZ)'Change BT_LINK_3 to whatever it is for youoUIObj.SetControlProperty "BT_LINK_3", "Visible", 1oUIObj.SetControlProperty "BT_LINK_3", "Text$", "Mem=" & CStr(vbDSZFormatted)

@Alnoor - Is it possible that users having multiple Sales Order Entry screens open at once could contribute, or does each screen each get a full 32mb?

Lee - Last week I responded to @Phil McIntosh about this. I'm assuming this is the same client for you guys. @Kevin Moyes and I mentioned there this could be another variation of the 64-bit script timeout issue but Phil mentioned this was a 32-bit system, so it wasn't that. I told Phil it could be something else and I would post a sample script soon to detect that. I will try to do so by this evening.

You may remember that in pvx, every screen only gets a max 32MB of workspace memory despite the amount of system memory present. Sage object code does a good job of DROP OBJECT and other things for memory management / garbage collection so that number never gets close to 0. However, with mods and scripts, we have to do the same thing, otherwise at some point in the day, that S/O Entry screen that's been working fine will potentially crash in some way.

** So a PostRead script can be created to show the available workspace memory based on the pvx DSZ system variable and placed in a UDF. I'll post that sample soon. The point here is when they report the Error 88 now you can now check to see if they are out of memory. 

Place this snippet at the top and you should be good. This is needed for business scripts but not for UI scripts, and not for button scripts. I usually have a bit at the top of every script that checks to see if we're sitting in a UI to begin with and then does this bit:

@Alnoor Cassim,  I put this on a Sales Order Header Post Read event and it gives an Error 88 Object required:  
oUIObj, SY_MAINT.PVC 3480 in CallScript 

No each screen gets 32MB. OK here is how to figure out available workspace memory. Even if this is not the cause of the Error 88 at least this possibility will have been eliminated.

'Get available workspace memory. 'Either create a new Customizer button with no desc OR create a numeric UDF'Create a PostRead script and attach this to itrV =oScript.DebugPrint("About to get DSZ")rV = oScript.Execute("tmpDSZ = DSZ")vbDSZ = oScript.Evaluate("tmpDSZ")vbDSZFormatted = FormatNumber(vbDSZ,0,,,-1)'Now either set the button text OR SetValue into the UDF'retVal = oBusObj.SetValue("UDF_DSZ", vbDSZ)'Change BT_LINK_3 to whatever it is for youoUIObj.SetControlProperty "BT_LINK_3", "Visible", 1oUIObj.SetControlProperty "BT_LINK_3", "Text$", "Mem=" & CStr(vbDSZFormatted)

@Alnoor - Is it possible that users having multiple Sales Order Entry screens open at once could contribute, or does each screen each get a full 32mb?

Lee - Last week I responded to @Phil McIntosh about this. I'm assuming this is the same client for you guys. @Kevin Moyes and I mentioned there this could be another variation of the 64-bit script timeout issue but Phil mentioned this was a 32-bit system, so it wasn't that. I told Phil it could be something else and I would post a sample script soon to detect that. I will try to do so by this evening.

You may remember that in pvx, every screen only gets a max 32MB of workspace memory despite the amount of system memory present. Sage object code does a good job of DROP OBJECT and other things for memory management / garbage collection so that number never gets close to 0. However, with mods and scripts, we have to do the same thing, otherwise at some point in the day, that S/O Entry screen that's been working fine will potentially crash in some way.

** So a PostRead script can be created to show the available workspace memory based on the pvx DSZ system variable and placed in a UDF. I'll post that sample soon. The point here is when they report the Error 88 now you can now check to see if they are out of memory. 

Thanks!  That did it.  Any idea what number would indicate it's time to close the window and open another?

Place this snippet at the top and you should be good. This is needed for business scripts but not for UI scripts, and not for button scripts. I usually have a bit at the top of every script that checks to see if we're sitting in a UI to begin with and then does this bit:

@Alnoor Cassim,  I put this on a Sales Order Header Post Read event and it gives an Error 88 Object required:  
oUIObj, SY_MAINT.PVC 3480 in CallScript 

No each screen gets 32MB. OK here is how to figure out available workspace memory. Even if this is not the cause of the Error 88 at least this possibility will have been eliminated.

'Get available workspace memory. 'Either create a new Customizer button with no desc OR create a numeric UDF'Create a PostRead script and attach this to itrV =oScript.DebugPrint("About to get DSZ")rV = oScript.Execute("tmpDSZ = DSZ")vbDSZ = oScript.Evaluate("tmpDSZ")vbDSZFormatted = FormatNumber(vbDSZ,0,,,-1)'Now either set the button text OR SetValue into the UDF'retVal = oBusObj.SetValue("UDF_DSZ", vbDSZ)'Change BT_LINK_3 to whatever it is for youoUIObj.SetControlProperty "BT_LINK_3", "Visible", 1oUIObj.SetControlProperty "BT_LINK_3", "Text$", "Mem=" & CStr(vbDSZFormatted)

@Alnoor - Is it possible that users having multiple Sales Order Entry screens open at once could contribute, or does each screen each get a full 32mb?

Lee - Last week I responded to @Phil McIntosh about this. I'm assuming this is the same client for you guys. @Kevin Moyes and I mentioned there this could be another variation of the 64-bit script timeout issue but Phil mentioned this was a 32-bit system, so it wasn't that. I told Phil it could be something else and I would post a sample script soon to detect that. I will try to do so by this evening.

You may remember that in pvx, every screen only gets a max 32MB of workspace memory despite the amount of system memory present. Sage object code does a good job of DROP OBJECT and other things for memory management / garbage collection so that number never gets close to 0. However, with mods and scripts, we have to do the same thing, otherwise at some point in the day, that S/O Entry screen that's been working fine will potentially crash in some way.

** So a PostRead script can be created to show the available workspace memory based on the pvx DSZ system variable and placed in a UDF. I'll post that sample soon. The point here is when they report the Error 88 now you can now check to see if they are out of memory. 

I would look for the number to fall below 1.5 MB (which is 1,500,000 as you would see it). You could even adjust the script to pop such a warning.

Thanks!  That did it.  Any idea what number would indicate it's time to close the window and open another?

Place this snippet at the top and you should be good. This is needed for business scripts but not for UI scripts, and not for button scripts. I usually have a bit at the top of every script that checks to see if we're sitting in a UI to begin with and then does this bit:

@Alnoor Cassim,  I put this on a Sales Order Header Post Read event and it gives an Error 88 Object required:  
oUIObj, SY_MAINT.PVC 3480 in CallScript 

No each screen gets 32MB. OK here is how to figure out available workspace memory. Even if this is not the cause of the Error 88 at least this possibility will have been eliminated.

'Get available workspace memory. 'Either create a new Customizer button with no desc OR create a numeric UDF'Create a PostRead script and attach this to itrV =oScript.DebugPrint("About to get DSZ")rV = oScript.Execute("tmpDSZ = DSZ")vbDSZ = oScript.Evaluate("tmpDSZ")vbDSZFormatted = FormatNumber(vbDSZ,0,,,-1)'Now either set the button text OR SetValue into the UDF'retVal = oBusObj.SetValue("UDF_DSZ", vbDSZ)'Change BT_LINK_3 to whatever it is for youoUIObj.SetControlProperty "BT_LINK_3", "Visible", 1oUIObj.SetControlProperty "BT_LINK_3", "Text$", "Mem=" & CStr(vbDSZFormatted)

@Alnoor - Is it possible that users having multiple Sales Order Entry screens open at once could contribute, or does each screen each get a full 32mb?

Lee - Last week I responded to @Phil McIntosh about this. I'm assuming this is the same client for you guys. @Kevin Moyes and I mentioned there this could be another variation of the 64-bit script timeout issue but Phil mentioned this was a 32-bit system, so it wasn't that. I told Phil it could be something else and I would post a sample script soon to detect that. I will try to do so by this evening.

You may remember that in pvx, every screen only gets a max 32MB of workspace memory despite the amount of system memory present. Sage object code does a good job of DROP OBJECT and other things for memory management / garbage collection so that number never gets close to 0. However, with mods and scripts, we have to do the same thing, otherwise at some point in the day, that S/O Entry screen that's been working fine will potentially crash in some way.

** So a PostRead script can be created to show the available workspace memory based on the pvx DSZ system variable and placed in a UDF. I'll post that sample soon. The point here is when they report the Error 88 now you can now check to see if they are out of memory. 

Place this snippet at the top and you should be good. This is needed for business scripts but not for UI scripts, and not for button scripts. I usually have a bit at the top of every script that checks to see if we're sitting in a UI to begin with and then does this bit:

@Alnoor Cassim,  I put this on a Sales Order Header Post Read event and it gives an Error 88 Object required:  
oUIObj, SY_MAINT.PVC 3480 in CallScript 

No each screen gets 32MB. OK here is how to figure out available workspace memory. Even if this is not the cause of the Error 88 at least this possibility will have been eliminated.

'Get available workspace memory. 'Either create a new Customizer button with no desc OR create a numeric UDF'Create a PostRead script and attach this to itrV =oScript.DebugPrint("About to get DSZ")rV = oScript.Execute("tmpDSZ = DSZ")vbDSZ = oScript.Evaluate("tmpDSZ")vbDSZFormatted = FormatNumber(vbDSZ,0,,,-1)'Now either set the button text OR SetValue into the UDF'retVal = oBusObj.SetValue("UDF_DSZ", vbDSZ)'Change BT_LINK_3 to whatever it is for youoUIObj.SetControlProperty "BT_LINK_3", "Visible", 1oUIObj.SetControlProperty "BT_LINK_3", "Text$", "Mem=" & CStr(vbDSZFormatted)

@Alnoor - Is it possible that users having multiple Sales Order Entry screens open at once could contribute, or does each screen each get a full 32mb?

Lee - Last week I responded to @Phil McIntosh about this. I'm assuming this is the same client for you guys. @Kevin Moyes and I mentioned there this could be another variation of the 64-bit script timeout issue but Phil mentioned this was a 32-bit system, so it wasn't that. I told Phil it could be something else and I would post a sample script soon to detect that. I will try to do so by this evening.

You may remember that in pvx, every screen only gets a max 32MB of workspace memory despite the amount of system memory present. Sage object code does a good job of DROP OBJECT and other things for memory management / garbage collection so that number never gets close to 0. However, with mods and scripts, we have to do the same thing, otherwise at some point in the day, that S/O Entry screen that's been working fine will potentially crash in some way.

** So a PostRead script can be created to show the available workspace memory based on the pvx DSZ system variable and placed in a UDF. I'll post that sample soon. The point here is when they report the Error 88 now you can now check to see if they are out of memory. 

@Alnoor Cassim - Is there a way to have this script not fire if the call is from a BOI app?  We have an integration BOI app that started failing on Sales Order SetKey with this script in place, and runs normally again with it removed.

Place this snippet at the top and you should be good. This is needed for business scripts but not for UI scripts, and not for button scripts. I usually have a bit at the top of every script that checks to see if we're sitting in a UI to begin with and then does this bit:

@Alnoor Cassim,  I put this on a Sales Order Header Post Read event and it gives an Error 88 Object required:  
oUIObj, SY_MAINT.PVC 3480 in CallScript 

No each screen gets 32MB. OK here is how to figure out available workspace memory. Even if this is not the cause of the Error 88 at least this possibility will have been eliminated.

'Get available workspace memory. 'Either create a new Customizer button with no desc OR create a numeric UDF'Create a PostRead script and attach this to itrV =oScript.DebugPrint("About to get DSZ")rV = oScript.Execute("tmpDSZ = DSZ")vbDSZ = oScript.Evaluate("tmpDSZ")vbDSZFormatted = FormatNumber(vbDSZ,0,,,-1)'Now either set the button text OR SetValue into the UDF'retVal = oBusObj.SetValue("UDF_DSZ", vbDSZ)'Change BT_LINK_3 to whatever it is for youoUIObj.SetControlProperty "BT_LINK_3", "Visible", 1oUIObj.SetControlProperty "BT_LINK_3", "Text$", "Mem=" & CStr(vbDSZFormatted)

@Alnoor - Is it possible that users having multiple Sales Order Entry screens open at once could contribute, or does each screen each get a full 32mb?

Lee - Last week I responded to @Phil McIntosh about this. I'm assuming this is the same client for you guys. @Kevin Moyes and I mentioned there this could be another variation of the 64-bit script timeout issue but Phil mentioned this was a 32-bit system, so it wasn't that. I told Phil it could be something else and I would post a sample script soon to detect that. I will try to do so by this evening.

You may remember that in pvx, every screen only gets a max 32MB of workspace memory despite the amount of system memory present. Sage object code does a good job of DROP OBJECT and other things for memory management / garbage collection so that number never gets close to 0. However, with mods and scripts, we have to do the same thing, otherwise at some point in the day, that S/O Entry screen that's been working fine will potentially crash in some way.

** So a PostRead script can be created to show the available workspace memory based on the pvx DSZ system variable and placed in a UDF. I'll post that sample soon. The point here is when they report the Error 88 now you can now check to see if they are out of memory. 

This is from my notes... not sure where I found the reference:

If oSession.ObjectInterface = 0 Then

    ' Launched from Sage 100 Desktop

End If

If oSession.ObjectInterface <> 0 Then

    ' Launched from COM object

End If

@Alnoor Cassim - Is there a way to have this script not fire if the call is from a BOI app?  We have an integration BOI app that started failing on Sales Order SetKey with this script in place, and runs normally again with it removed.

Place this snippet at the top and you should be good. This is needed for business scripts but not for UI scripts, and not for button scripts. I usually have a bit at the top of every script that checks to see if we're sitting in a UI to begin with and then does this bit:

@Alnoor Cassim,  I put this on a Sales Order Header Post Read event and it gives an Error 88 Object required:  
oUIObj, SY_MAINT.PVC 3480 in CallScript 

No each screen gets 32MB. OK here is how to figure out available workspace memory. Even if this is not the cause of the Error 88 at least this possibility will have been eliminated.

'Get available workspace memory. 'Either create a new Customizer button with no desc OR create a numeric UDF'Create a PostRead script and attach this to itrV =oScript.DebugPrint("About to get DSZ")rV = oScript.Execute("tmpDSZ = DSZ")vbDSZ = oScript.Evaluate("tmpDSZ")vbDSZFormatted = FormatNumber(vbDSZ,0,,,-1)'Now either set the button text OR SetValue into the UDF'retVal = oBusObj.SetValue("UDF_DSZ", vbDSZ)'Change BT_LINK_3 to whatever it is for youoUIObj.SetControlProperty "BT_LINK_3", "Visible", 1oUIObj.SetControlProperty "BT_LINK_3", "Text$", "Mem=" & CStr(vbDSZFormatted)

@Alnoor - Is it possible that users having multiple Sales Order Entry screens open at once could contribute, or does each screen each get a full 32mb?

Lee - Last week I responded to @Phil McIntosh about this. I'm assuming this is the same client for you guys. @Kevin Moyes and I mentioned there this could be another variation of the 64-bit script timeout issue but Phil mentioned this was a 32-bit system, so it wasn't that. I told Phil it could be something else and I would post a sample script soon to detect that. I will try to do so by this evening.

You may remember that in pvx, every screen only gets a max 32MB of workspace memory despite the amount of system memory present. Sage object code does a good job of DROP OBJECT and other things for memory management / garbage collection so that number never gets close to 0. However, with mods and scripts, we have to do the same thing, otherwise at some point in the day, that S/O Entry screen that's been working fine will potentially crash in some way.

** So a PostRead script can be created to show the available workspace memory based on the pvx DSZ system variable and placed in a UDF. I'll post that sample soon. The point here is when they report the Error 88 now you can now check to see if they are out of memory. 

Lee - Last week I responded to @Phil McIntosh about this. I'm assuming this is the same client for you guys. @Kevin Moyes and I mentioned there this could be another variation of the 64-bit script timeout issue but Phil mentioned this was a 32-bit system, so it wasn't that. I told Phil it could be something else and I would post a sample script soon to detect that. I will try to do so by this evening.

You may remember that in pvx, every screen only gets a max 32MB of workspace memory despite the amount of system memory present. Sage object code does a good job of DROP OBJECT and other things for memory management / garbage collection so that number never gets close to 0. However, with mods and scripts, we have to do the same thing, otherwise at some point in the day, that S/O Entry screen that's been working fine will potentially crash in some way.

** So a PostRead script can be created to show the available workspace memory based on the pvx DSZ system variable and placed in a UDF. I'll post that sample soon. The point here is when they report the Error 88 now you can now check to see if they are out of memory. 

One habit I have started (for button scripts especially) is to manually reset any object I created manually.  (Obviously don't do this for oBusObj...).

Lee - Last week I responded to @Phil McIntosh about this. I'm assuming this is the same client for you guys. @Kevin Moyes and I mentioned there this could be another variation of the 64-bit script timeout issue but Phil mentioned this was a 32-bit system, so it wasn't that. I told Phil it could be something else and I would post a sample script soon to detect that. I will try to do so by this evening.

You may remember that in pvx, every screen only gets a max 32MB of workspace memory despite the amount of system memory present. Sage object code does a good job of DROP OBJECT and other things for memory management / garbage collection so that number never gets close to 0. However, with mods and scripts, we have to do the same thing, otherwise at some point in the day, that S/O Entry screen that's been working fine will potentially crash in some way.

** So a PostRead script can be created to show the available workspace memory based on the pvx DSZ system variable and placed in a UDF. I'll post that sample soon. The point here is when they report the Error 88 now you can now check to see if they are out of memory. 

this can be removed from urgent...

One habit I have started (for button scripts especially) is to manually reset any object I created manually.  (Obviously don't do this for oBusObj...).

Lee - Last week I responded to @Phil McIntosh about this. I'm assuming this is the same client for you guys. @Kevin Moyes and I mentioned there this could be another variation of the 64-bit script timeout issue but Phil mentioned this was a 32-bit system, so it wasn't that. I told Phil it could be something else and I would post a sample script soon to detect that. I will try to do so by this evening.

You may remember that in pvx, every screen only gets a max 32MB of workspace memory despite the amount of system memory present. Sage object code does a good job of DROP OBJECT and other things for memory management / garbage collection so that number never gets close to 0. However, with mods and scripts, we have to do the same thing, otherwise at some point in the day, that S/O Entry screen that's been working fine will potentially crash in some way.

** So a PostRead script can be created to show the available workspace memory based on the pvx DSZ system variable and placed in a UDF. I'll post that sample soon. The point here is when they report the Error 88 now you can now check to see if they are out of memory.