Sage 100

Do you know what the scripts are trying to do?

Those errors are usually red herrings because they are the last warning set in the oSession object before a method fails silently.  I think I saw them most often back when Sage changes which crystal runtime was used and so if there is a conflict, the report engine or report common class would fail silently in the ON_CREATE section.

Can the user preview reports on this affected workstation?

Do you know what the scripts are trying to do?

Those errors are usually red herrings because they are the last warning set in the oSession object before a method fails silently.  I think I saw them most often back when Sage changes which crystal runtime was used and so if there is a conflict, the report engine or report common class would fail silently in the ON_CREATE section.

Can the user preview reports on this affected workstation?

Do you know what the scripts are trying to do?

Those errors are usually red herrings because they are the last warning set in the oSession object before a method fails silently.  I think I saw them most often back when Sage changes which crystal runtime was used and so if there is a conflict, the report engine or report common class would fail silently in the ON_CREATE section.

Can the user preview reports on this affected workstation?

Is Avalara installed and are there any BOI type scripts running (meaning they would execute at the wkstn) ? If so have you tried copying down the \mas90\Avatax folder to C:\Sage and running the register_for_com.bat from there

@Alnoor Cassim - no Avalara, either.  NO 3rd party.  Just these scripts.

Is Avalara installed and are there any BOI type scripts running (meaning they would execute at the wkstn) ? If so have you tried copying down the \mas90\Avatax folder to C:\Sage and running the register_for_com.bat from there

I reviewed the two scripts that I have on file for them and did not see anything in the scripts that would typically cause this.  You mentioned .Net 3.5 not being installed originally, I wonder if something is blocking the script host on that workstation.  One way to test would be to create a test script that can be triggered on any table and event and just put a single quote in it and compile the script.  If the event causes the error for that workstation but not on any others, then I think it is an issue with the script host.  Could try a complete uninstall, reboot, and reinstall.

@Alnoor Cassim - no Avalara, either.  NO 3rd party.  Just these scripts.

Is Avalara installed and are there any BOI type scripts running (meaning they would execute at the wkstn) ? If so have you tried copying down the \mas90\Avatax folder to C:\Sage and running the register_for_com.bat from there

Watch for Anti-Virus blocking scripts.  We had a client that tried to lock down vbscripts entirely, which obviously didn't last long when it was explained how Sage 100 technically implemented UDS.

I reviewed the two scripts that I have on file for them and did not see anything in the scripts that would typically cause this.  You mentioned .Net 3.5 not being installed originally, I wonder if something is blocking the script host on that workstation.  One way to test would be to create a test script that can be triggered on any table and event and just put a single quote in it and compile the script.  If the event causes the error for that workstation but not on any others, then I think it is an issue with the script host.  Could try a complete uninstall, reboot, and reinstall.

@Alnoor Cassim - no Avalara, either.  NO 3rd party.  Just these scripts.

Is Avalara installed and are there any BOI type scripts running (meaning they would execute at the wkstn) ? If so have you tried copying down the \mas90\Avatax folder to C:\Sage and running the register_for_com.bat from there

I reviewed the two scripts that I have on file for them and did not see anything in the scripts that would typically cause this.  You mentioned .Net 3.5 not being installed originally, I wonder if something is blocking the script host on that workstation.  One way to test would be to create a test script that can be triggered on any table and event and just put a single quote in it and compile the script.  If the event causes the error for that workstation but not on any others, then I think it is an issue with the script host.  Could try a complete uninstall, reboot, and reinstall.

@Alnoor Cassim - no Avalara, either.  NO 3rd party.  Just these scripts.

Is Avalara installed and are there any BOI type scripts running (meaning they would execute at the wkstn) ? If so have you tried copying down the \mas90\Avatax folder to C:\Sage and running the register_for_com.bat from there

Is there something in Internet Options that would affect this?  IT has uninstalled, rebooted, reinstalled about 3 times before we got to this point.

I reviewed the two scripts that I have on file for them and did not see anything in the scripts that would typically cause this.  You mentioned .Net 3.5 not being installed originally, I wonder if something is blocking the script host on that workstation.  One way to test would be to create a test script that can be triggered on any table and event and just put a single quote in it and compile the script.  If the event causes the error for that workstation but not on any others, then I think it is an issue with the script host.  Could try a complete uninstall, reboot, and reinstall.

@Alnoor Cassim - no Avalara, either.  NO 3rd party.  Just these scripts.

Is Avalara installed and are there any BOI type scripts running (meaning they would execute at the wkstn) ? If so have you tried copying down the \mas90\Avatax folder to C:\Sage and running the register_for_com.bat from there

Had the client call Sage and the first tech had him turn off External Access because he didn't understand client said they weren't using the script ON THAT MACHINE, not that they weren't using the script period.  Second one thinks it's a script error (although runs fine everywhere else) and threw it back to reseller.  I knew better, but thought MAYBE someone would be helpful there.

Is there something in Internet Options that would affect this?  IT has uninstalled, rebooted, reinstalled about 3 times before we got to this point.

I reviewed the two scripts that I have on file for them and did not see anything in the scripts that would typically cause this.  You mentioned .Net 3.5 not being installed originally, I wonder if something is blocking the script host on that workstation.  One way to test would be to create a test script that can be triggered on any table and event and just put a single quote in it and compile the script.  If the event causes the error for that workstation but not on any others, then I think it is an issue with the script host.  Could try a complete uninstall, reboot, and reinstall.

@Alnoor Cassim - no Avalara, either.  NO 3rd party.  Just these scripts.

Is Avalara installed and are there any BOI type scripts running (meaning they would execute at the wkstn) ? If so have you tried copying down the \mas90\Avatax folder to C:\Sage and running the register_for_com.bat from there

Does the error come up if the same user tries from a different workstation (that works for other users)?  This should help eliminate a Sage permission issue.

Had the client call Sage and the first tech had him turn off External Access because he didn't understand client said they weren't using the script ON THAT MACHINE, not that they weren't using the script period.  Second one thinks it's a script error (although runs fine everywhere else) and threw it back to reseller.  I knew better, but thought MAYBE someone would be helpful there.

Is there something in Internet Options that would affect this?  IT has uninstalled, rebooted, reinstalled about 3 times before we got to this point.

I reviewed the two scripts that I have on file for them and did not see anything in the scripts that would typically cause this.  You mentioned .Net 3.5 not being installed originally, I wonder if something is blocking the script host on that workstation.  One way to test would be to create a test script that can be triggered on any table and event and just put a single quote in it and compile the script.  If the event causes the error for that workstation but not on any others, then I think it is an issue with the script host.  Could try a complete uninstall, reboot, and reinstall.

@Alnoor Cassim - no Avalara, either.  NO 3rd party.  Just these scripts.

Is Avalara installed and are there any BOI type scripts running (meaning they would execute at the wkstn) ? If so have you tried copying down the \mas90\Avatax folder to C:\Sage and running the register_for_com.bat from there

No, it does not.

Does the error come up if the same user tries from a different workstation (that works for other users)?  This should help eliminate a Sage permission issue.

Had the client call Sage and the first tech had him turn off External Access because he didn't understand client said they weren't using the script ON THAT MACHINE, not that they weren't using the script period.  Second one thinks it's a script error (although runs fine everywhere else) and threw it back to reseller.  I knew better, but thought MAYBE someone would be helpful there.

Is there something in Internet Options that would affect this?  IT has uninstalled, rebooted, reinstalled about 3 times before we got to this point.

I reviewed the two scripts that I have on file for them and did not see anything in the scripts that would typically cause this.  You mentioned .Net 3.5 not being installed originally, I wonder if something is blocking the script host on that workstation.  One way to test would be to create a test script that can be triggered on any table and event and just put a single quote in it and compile the script.  If the event causes the error for that workstation but not on any others, then I think it is an issue with the script host.  Could try a complete uninstall, reboot, and reinstall.

@Alnoor Cassim - no Avalara, either.  NO 3rd party.  Just these scripts.

Is Avalara installed and are there any BOI type scripts running (meaning they would execute at the wkstn) ? If so have you tried copying down the \mas90\Avatax folder to C:\Sage and running the register_for_com.bat from there

UAC off (registry hack, reboot) then uninstall / reinstall the workstation (when logged into Windows as a local administrator)?  That's helped with quite a few stubborn workstation issues in the past.  (Set EnableLUA back to 1 after the install... especially on Win11).

No, it does not.

Does the error come up if the same user tries from a different workstation (that works for other users)?  This should help eliminate a Sage permission issue.

Had the client call Sage and the first tech had him turn off External Access because he didn't understand client said they weren't using the script ON THAT MACHINE, not that they weren't using the script period.  Second one thinks it's a script error (although runs fine everywhere else) and threw it back to reseller.  I knew better, but thought MAYBE someone would be helpful there.

Is there something in Internet Options that would affect this?  IT has uninstalled, rebooted, reinstalled about 3 times before we got to this point.

I reviewed the two scripts that I have on file for them and did not see anything in the scripts that would typically cause this.  You mentioned .Net 3.5 not being installed originally, I wonder if something is blocking the script host on that workstation.  One way to test would be to create a test script that can be triggered on any table and event and just put a single quote in it and compile the script.  If the event causes the error for that workstation but not on any others, then I think it is an issue with the script host.  Could try a complete uninstall, reboot, and reinstall.

@Alnoor Cassim - no Avalara, either.  NO 3rd party.  Just these scripts.

Is Avalara installed and are there any BOI type scripts running (meaning they would execute at the wkstn) ? If so have you tried copying down the \mas90\Avatax folder to C:\Sage and running the register_for_com.bat from there

No, it does not.

Does the error come up if the same user tries from a different workstation (that works for other users)?  This should help eliminate a Sage permission issue.

Had the client call Sage and the first tech had him turn off External Access because he didn't understand client said they weren't using the script ON THAT MACHINE, not that they weren't using the script period.  Second one thinks it's a script error (although runs fine everywhere else) and threw it back to reseller.  I knew better, but thought MAYBE someone would be helpful there.

Is there something in Internet Options that would affect this?  IT has uninstalled, rebooted, reinstalled about 3 times before we got to this point.

I reviewed the two scripts that I have on file for them and did not see anything in the scripts that would typically cause this.  You mentioned .Net 3.5 not being installed originally, I wonder if something is blocking the script host on that workstation.  One way to test would be to create a test script that can be triggered on any table and event and just put a single quote in it and compile the script.  If the event causes the error for that workstation but not on any others, then I think it is an issue with the script host.  Could try a complete uninstall, reboot, and reinstall.

@Alnoor Cassim - no Avalara, either.  NO 3rd party.  Just these scripts.

Is Avalara installed and are there any BOI type scripts running (meaning they would execute at the wkstn) ? If so have you tried copying down the \mas90\Avatax folder to C:\Sage and running the register_for_com.bat from there

Beth were you able to get someone in IT to check if scripts are locked down from that PC? You could try just creating a silly external 1-line Hello.vbs file and double-clicking it to see if it gives you an error, something like:

MsgBox "Hello World in turbulence" 

If you get an error, it means either the Windows Scripting Host is not installed as David mentioned or something is blocking it. If the latter, the error might even pop up with a message like "McAfee Total Protection has blocked this script from executing".

Also, a ProcMon (Process Monitor) trace may capture the culprit application as well that's blocking the script.

No, it does not.

Does the error come up if the same user tries from a different workstation (that works for other users)?  This should help eliminate a Sage permission issue.

Had the client call Sage and the first tech had him turn off External Access because he didn't understand client said they weren't using the script ON THAT MACHINE, not that they weren't using the script period.  Second one thinks it's a script error (although runs fine everywhere else) and threw it back to reseller.  I knew better, but thought MAYBE someone would be helpful there.

Is there something in Internet Options that would affect this?  IT has uninstalled, rebooted, reinstalled about 3 times before we got to this point.

I reviewed the two scripts that I have on file for them and did not see anything in the scripts that would typically cause this.  You mentioned .Net 3.5 not being installed originally, I wonder if something is blocking the script host on that workstation.  One way to test would be to create a test script that can be triggered on any table and event and just put a single quote in it and compile the script.  If the event causes the error for that workstation but not on any others, then I think it is an issue with the script host.  Could try a complete uninstall, reboot, and reinstall.

@Alnoor Cassim - no Avalara, either.  NO 3rd party.  Just these scripts.

Is Avalara installed and are there any BOI type scripts running (meaning they would execute at the wkstn) ? If so have you tried copying down the \mas90\Avatax folder to C:\Sage and running the register_for_com.bat from there

@Alnoor Cassim - I thought he did, but will send this and confirm

Beth were you able to get someone in IT to check if scripts are locked down from that PC? You could try just creating a silly external 1-line Hello.vbs file and double-clicking it to see if it gives you an error, something like:

MsgBox "Hello World in turbulence" 

If you get an error, it means either the Windows Scripting Host is not installed as David mentioned or something is blocking it. If the latter, the error might even pop up with a message like "McAfee Total Protection has blocked this script from executing".

Also, a ProcMon (Process Monitor) trace may capture the culprit application as well that's blocking the script.

No, it does not.

Does the error come up if the same user tries from a different workstation (that works for other users)?  This should help eliminate a Sage permission issue.

Had the client call Sage and the first tech had him turn off External Access because he didn't understand client said they weren't using the script ON THAT MACHINE, not that they weren't using the script period.  Second one thinks it's a script error (although runs fine everywhere else) and threw it back to reseller.  I knew better, but thought MAYBE someone would be helpful there.

Is there something in Internet Options that would affect this?  IT has uninstalled, rebooted, reinstalled about 3 times before we got to this point.

I reviewed the two scripts that I have on file for them and did not see anything in the scripts that would typically cause this.  You mentioned .Net 3.5 not being installed originally, I wonder if something is blocking the script host on that workstation.  One way to test would be to create a test script that can be triggered on any table and event and just put a single quote in it and compile the script.  If the event causes the error for that workstation but not on any others, then I think it is an issue with the script host.  Could try a complete uninstall, reboot, and reinstall.

@Alnoor Cassim - no Avalara, either.  NO 3rd party.  Just these scripts.

Is Avalara installed and are there any BOI type scripts running (meaning they would execute at the wkstn) ? If so have you tried copying down the \mas90\Avatax folder to C:\Sage and running the register_for_com.bat from there

ACK, this is still going on.  He was able to run a little script - WTH? Sage involved a second time and still no love.

@Alnoor Cassim - I thought he did, but will send this and confirm

Beth were you able to get someone in IT to check if scripts are locked down from that PC? You could try just creating a silly external 1-line Hello.vbs file and double-clicking it to see if it gives you an error, something like:

MsgBox "Hello World in turbulence" 

If you get an error, it means either the Windows Scripting Host is not installed as David mentioned or something is blocking it. If the latter, the error might even pop up with a message like "McAfee Total Protection has blocked this script from executing".

Also, a ProcMon (Process Monitor) trace may capture the culprit application as well that's blocking the script.

No, it does not.

Does the error come up if the same user tries from a different workstation (that works for other users)?  This should help eliminate a Sage permission issue.

Had the client call Sage and the first tech had him turn off External Access because he didn't understand client said they weren't using the script ON THAT MACHINE, not that they weren't using the script period.  Second one thinks it's a script error (although runs fine everywhere else) and threw it back to reseller.  I knew better, but thought MAYBE someone would be helpful there.

Is there something in Internet Options that would affect this?  IT has uninstalled, rebooted, reinstalled about 3 times before we got to this point.

I reviewed the two scripts that I have on file for them and did not see anything in the scripts that would typically cause this.  You mentioned .Net 3.5 not being installed originally, I wonder if something is blocking the script host on that workstation.  One way to test would be to create a test script that can be triggered on any table and event and just put a single quote in it and compile the script.  If the event causes the error for that workstation but not on any others, then I think it is an issue with the script host.  Could try a complete uninstall, reboot, and reinstall.

@Alnoor Cassim - no Avalara, either.  NO 3rd party.  Just these scripts.

Is Avalara installed and are there any BOI type scripts running (meaning they would execute at the wkstn) ? If so have you tried copying down the \mas90\Avatax folder to C:\Sage and running the register_for_com.bat from there

This is resolved. 

Here is the reason for this issue: The client is on version 2022 and running the 64-bit version of Sage 100.  Since Microsoft never released a 64-bit version of its script host but another company did, Sage had to rely on the third-party's tsc64.dll to run scripts on 64-bit versions of Sage 100.  The affected PCs failed to copy and register the dll from the server during the workstation installation.  

Here is the solution for this issue: Copy the MAS90\Home\tsc64.dll file on the server to the workstation's C:\Windows\System32 directory and then open an elevated command prompt and type the following.

regsvr32 "C\Windows\System32\tsc64.dll"

ACK, this is still going on.  He was able to run a little script - WTH? Sage involved a second time and still no love.

@Alnoor Cassim - I thought he did, but will send this and confirm

Beth were you able to get someone in IT to check if scripts are locked down from that PC? You could try just creating a silly external 1-line Hello.vbs file and double-clicking it to see if it gives you an error, something like:

MsgBox "Hello World in turbulence" 

If you get an error, it means either the Windows Scripting Host is not installed as David mentioned or something is blocking it. If the latter, the error might even pop up with a message like "McAfee Total Protection has blocked this script from executing".

Also, a ProcMon (Process Monitor) trace may capture the culprit application as well that's blocking the script.

No, it does not.

Does the error come up if the same user tries from a different workstation (that works for other users)?  This should help eliminate a Sage permission issue.

Had the client call Sage and the first tech had him turn off External Access because he didn't understand client said they weren't using the script ON THAT MACHINE, not that they weren't using the script period.  Second one thinks it's a script error (although runs fine everywhere else) and threw it back to reseller.  I knew better, but thought MAYBE someone would be helpful there.

Is there something in Internet Options that would affect this?  IT has uninstalled, rebooted, reinstalled about 3 times before we got to this point.

I reviewed the two scripts that I have on file for them and did not see anything in the scripts that would typically cause this.  You mentioned .Net 3.5 not being installed originally, I wonder if something is blocking the script host on that workstation.  One way to test would be to create a test script that can be triggered on any table and event and just put a single quote in it and compile the script.  If the event causes the error for that workstation but not on any others, then I think it is an issue with the script host.  Could try a complete uninstall, reboot, and reinstall.

@Alnoor Cassim - no Avalara, either.  NO 3rd party.  Just these scripts.

Is Avalara installed and are there any BOI type scripts running (meaning they would execute at the wkstn) ? If so have you tried copying down the \mas90\Avatax folder to C:\Sage and running the register_for_com.bat from there

This is resolved. 

Here is the reason for this issue: The client is on version 2022 and running the 64-bit version of Sage 100.  Since Microsoft never released a 64-bit version of its script host but another company did, Sage had to rely on the third-party's tsc64.dll to run scripts on 64-bit versions of Sage 100.  The affected PCs failed to copy and register the dll from the server during the workstation installation.  

Here is the solution for this issue: Copy the MAS90\Home\tsc64.dll file on the server to the workstation's C:\Windows\System32 directory and then open an elevated command prompt and type the following.

regsvr32 "C\Windows\System32\tsc64.dll"

ACK, this is still going on.  He was able to run a little script - WTH? Sage involved a second time and still no love.

@Alnoor Cassim - I thought he did, but will send this and confirm

Beth were you able to get someone in IT to check if scripts are locked down from that PC? You could try just creating a silly external 1-line Hello.vbs file and double-clicking it to see if it gives you an error, something like:

MsgBox "Hello World in turbulence" 

If you get an error, it means either the Windows Scripting Host is not installed as David mentioned or something is blocking it. If the latter, the error might even pop up with a message like "McAfee Total Protection has blocked this script from executing".

Also, a ProcMon (Process Monitor) trace may capture the culprit application as well that's blocking the script.

No, it does not.

Does the error come up if the same user tries from a different workstation (that works for other users)?  This should help eliminate a Sage permission issue.

Had the client call Sage and the first tech had him turn off External Access because he didn't understand client said they weren't using the script ON THAT MACHINE, not that they weren't using the script period.  Second one thinks it's a script error (although runs fine everywhere else) and threw it back to reseller.  I knew better, but thought MAYBE someone would be helpful there.

Is there something in Internet Options that would affect this?  IT has uninstalled, rebooted, reinstalled about 3 times before we got to this point.

I reviewed the two scripts that I have on file for them and did not see anything in the scripts that would typically cause this.  You mentioned .Net 3.5 not being installed originally, I wonder if something is blocking the script host on that workstation.  One way to test would be to create a test script that can be triggered on any table and event and just put a single quote in it and compile the script.  If the event causes the error for that workstation but not on any others, then I think it is an issue with the script host.  Could try a complete uninstall, reboot, and reinstall.

@Alnoor Cassim - no Avalara, either.  NO 3rd party.  Just these scripts.

Is Avalara installed and are there any BOI type scripts running (meaning they would execute at the wkstn) ? If so have you tried copying down the \mas90\Avatax folder to C:\Sage and running the register_for_com.bat from there

Well done @David Speck II !!

This is resolved. 

Here is the reason for this issue: The client is on version 2022 and running the 64-bit version of Sage 100.  Since Microsoft never released a 64-bit version of its script host but another company did, Sage had to rely on the third-party's tsc64.dll to run scripts on 64-bit versions of Sage 100.  The affected PCs failed to copy and register the dll from the server during the workstation installation.  

Here is the solution for this issue: Copy the MAS90\Home\tsc64.dll file on the server to the workstation's C:\Windows\System32 directory and then open an elevated command prompt and type the following.

regsvr32 "C\Windows\System32\tsc64.dll"

ACK, this is still going on.  He was able to run a little script - WTH? Sage involved a second time and still no love.

@Alnoor Cassim - I thought he did, but will send this and confirm

Beth were you able to get someone in IT to check if scripts are locked down from that PC? You could try just creating a silly external 1-line Hello.vbs file and double-clicking it to see if it gives you an error, something like:

MsgBox "Hello World in turbulence" 

If you get an error, it means either the Windows Scripting Host is not installed as David mentioned or something is blocking it. If the latter, the error might even pop up with a message like "McAfee Total Protection has blocked this script from executing".

Also, a ProcMon (Process Monitor) trace may capture the culprit application as well that's blocking the script.

No, it does not.

Does the error come up if the same user tries from a different workstation (that works for other users)?  This should help eliminate a Sage permission issue.

Had the client call Sage and the first tech had him turn off External Access because he didn't understand client said they weren't using the script ON THAT MACHINE, not that they weren't using the script period.  Second one thinks it's a script error (although runs fine everywhere else) and threw it back to reseller.  I knew better, but thought MAYBE someone would be helpful there.

Is there something in Internet Options that would affect this?  IT has uninstalled, rebooted, reinstalled about 3 times before we got to this point.

I reviewed the two scripts that I have on file for them and did not see anything in the scripts that would typically cause this.  You mentioned .Net 3.5 not being installed originally, I wonder if something is blocking the script host on that workstation.  One way to test would be to create a test script that can be triggered on any table and event and just put a single quote in it and compile the script.  If the event causes the error for that workstation but not on any others, then I think it is an issue with the script host.  Could try a complete uninstall, reboot, and reinstall.

@Alnoor Cassim - no Avalara, either.  NO 3rd party.  Just these scripts.

Is Avalara installed and are there any BOI type scripts running (meaning they would execute at the wkstn) ? If so have you tried copying down the \mas90\Avatax folder to C:\Sage and running the register_for_com.bat from there