MSSCript control error on MS 10.1.02

grimeball · Post by **grimeball** » Fri Apr 18, 2008 6:49 pm

Am I looking for the vb script engine links?

Post by **Marcus Tettmar** » Fri Apr 18, 2008 6:58 pm

grimeball · Post by **grimeball** » Fri Apr 18, 2008 7:47 pm

OK. Downloaded the script engine from the Microsoft site, required a reboot of the PC, and still getting the same error on starting the script from an executable.

I have no idea what to try now to get this to run unattended.

The business process I want to do here is during the middle of the night, the script will kick off, take a backup of the database provided through the Point of Sale system I have. And then ftp the backup to my home PC.

My Home PC, which also has the POS system installed, will restore the backup, and then enter the sales information directly into my QUickbooks.

This is running into a wringer by now being able to run this unattended from the shop.

Post by **Marcus Tettmar** » Fri Apr 18, 2008 7:51 pm

Hmmm - very odd. One thing you could try - install Macro Scheduler on the target machine. The eval will do. That will install the script control in the process. Then see if your exe runs.

grimeball · Post by **grimeball** » Wed Apr 23, 2008 7:10 pm

Resolved-

I had to take the 3 files referenced in my initial post in this thread, and register them on the target machine.

vbscript.dll
msscript.ocx
scrrun.dll

The ocx file did not exist on the target machine.

And the 2 dll's were older versions than the ones on my PC. I simply took the 3 files from my PC and had them loaded and registered on the target.

armsys · Post by **armsys** » Wed Apr 23, 2008 11:49 pm

grimeball,
Thanks for sharing your solution with us.
The latest version of VBScript is 5.7 and can be downloaded from
http://www.microsoft.com/downloads/deta ... laylang=en

grimeball · Post by **grimeball** » Sat Apr 26, 2008 8:40 pm

One loose end is a question why the target PC had to have them installed/registered.

The documentation doesn't list any requirements for a computer to be able to run compiled exe's. I think this concretely demonstrates there are some.

I think MS is a wonderful product, and in combination with qodbc, I have fully automated a process to integrate my retail location Point of Sale Systems to my quickbooks. THis will save me over 15 hours a week already, plus a additional savings on the way as I automate payroll, and credit card deposit reconciliation.

Just putting this out there because there apparently is a minumumversion requirement of vbscript.

Post by **Marcus Tettmar** » Sat Apr 26, 2008 8:57 pm

To answer your question - msscript.ocx is installed by the EXE if it doesn't already exist AND is registered. As noted earler, when you compile the EXE the three files you mention are stuffed into the EXE. When the EXE is run it first checks to see if these files exist on the PC. If not, they are extracted AND registered. Therefore it is NOT a minimum requirement that they are already there. Hence no need for any documentation - Macro Scheduler and compiled EXEs are supposed to take care of these requirements. I can't explain why this didn't work on this particular PC.

jpuziano · Post by **jpuziano** » Sun Apr 27, 2008 2:27 am

grimeball wrote:One loose end is a question why the target PC had to have them installed/registered.

The documentation doesn't list any requirements for a computer to be able to run compiled exe's. I think this concretely demonstrates there are some.

mtettmar wrote:To answer your question - msscript.ocx is installed by the EXE if it doesn't already exist AND is registered. As noted earler, when you compile the EXE the three files you mention are stuffed into the EXE. When the EXE is run it first checks to see if these files exist on the PC. If not, they are extracted AND registered. Therefore it is NOT a minimum requirement that they are already there. Hence no need for any documentation - Macro Scheduler and compiled EXEs are supposed to take care of these requirements. I can't explain why this didn't work on this particular PC.

Well... no need for any documentation... if it always works. Looks like we may have a case here where it didn't work and the reason why is not yet known.

If the reason why is discovered then all is well. If not, then maybe adding a Topic to the Help file would be a good thing... to speed up the troubleshooting process for anyone who might run into this problem with compiled exe's in the future. Even something as small as this would help:

Potential new Help Topic wrote:Compiled Exe - Target PC Requirements

There are none. The following files...

vbscript.dll
msscript.ocx
scrrun.dll

...are required on the target machine but these files are also contained in every compiled exe. When the exe runs, it checks for them and any are not there, they are extracted and registered on the target PC.

This has been a very interesting topic. Thank you grimeball for posting your problem and solutions here for everyone's benefit. Thanks to all the posters that helped and thanks Marcus for explaining what is going on behind the scenes when a compiled exe is run... not yet documented... but very nice to know.

Me_again · Post by **Me_again** » Sun Apr 27, 2008 2:33 am

Well said JP, I've been watching this one with interest too.

grimeball · Post by **grimeball** » Mon Apr 28, 2008 8:05 pm

Thanks Marcus for the explanations, and others for the comments.

Marcus - could it be related that only 2 of the 3 files were on the PC, and there are version dependencies between them.

As I said, the PC had the 2 DLL's, but not the OCX. Is the versioning of these 3 files packaged together, and maybe the OCX in the exe was a different version that what would work with the older dll's that were already on the PC?

When you say the exe will install/register the files if they don't exist, is that for just the inprocess memory, or should I have expected to see the OCX in the system32 directory after the first time the exe was run. As I indicated, the OCX file was not in the System32 directory and I had to install it there myself.

JRL · Post by **JRL** » Mon Apr 28, 2008 9:03 pm

I like others have been watching this thread. From the evidence presented thus far it sounds like there is something about the PC that is causing the problem. For example the executable compiled by Bob also failed and the fact that no one seems to have heard of this before makes the PC (in my mind) the obvious starting point for investigation. So far I've not really noticed any discussion or questioning of the setup or condition of the PC.

Questions that come to mind:

What is the OS? Any potential conflict with anti virus software? What is the anti virus software? Is it infected with a virus? Any "high end" software installed such as CAD or other graphics manipulation? What is the condition of the hard drive? Is it old or failing? Is it full? Is it badly fragmented? Is it partitioned especially if it's partitioned with Partition Magic or some other similar software? What drive is the OS installed on? Are there multiple Operating systems? Is this a gaming computer?

Hopefully you can see where I'm going with this. What might be unusual about the PC that might prevent a file from being copied or registered?

Hope this is helpful,
Dick

edauthier · Post by **edauthier** » Tue Apr 29, 2008 3:07 am

I have never seen this before and I have installed MS compiled EXE's on some real 'stinker' PC's. Typically if there's an issue it's the script...

Look to AV or complete admistrative rights to the machine at installation time. Corrupt registry?

Scott, curious about machine specs, antivirus and other processes that could be running at same time as MS script.

grimeball · Post by **grimeball** » Tue Apr 29, 2008 9:11 pm

JRL wrote:I like others have been watching this thread. From the evidence presented thus far it sounds like there is something about the PC that is causing the problem. For example the executable compiled by Bob also failed and the fact that no one seems to have heard of this before makes the PC (in my mind) the obvious starting point for investigation. So far I've not really noticed any discussion or questioning of the setup or condition of the PC.

Questions that come to mind:

What is the OS? Any potential conflict with anti virus software? What is the anti virus software? Is it infected with a virus? Any "high end" software installed such as CAD or other graphics manipulation? What is the condition of the hard drive? Is it old or failing? Is it full? Is it badly fragmented? Is it partitioned especially if it's partitioned with Partition Magic or some other similar software? What drive is the OS installed on? Are there multiple Operating systems? Is this a gaming computer?

Hopefully you can see where I'm going with this. What might be unusual about the PC that might prevent a file from being copied or registered?

Hope this is helpful,
Dick

I'll try to answer as many of these questions as possible.

As a little background, this PC was at a car repair shop that I purchased when I took it over in 2006. I do not work at the shop on a frequent basis and it requires a 45 minute drive for me to get there. My father runs the business on a daily basis.

Unfortunately, I no one at the shop is very computer literate given the nature of the business.

It is an older PC (Dell). It has Windows XP SP2. I have no idea about the fragmentation of the drive, although, I would expect it to be fragmented.

The PC does not have an higher end software as it only access the internet and runs a proprietary Point of Sale system. It does not have much installed in terms of applications (IE...I had my dad install open office for office applications as it does not have MS Office.

I believe it runs Norton anti virus, although it does not have a subscription for definition file downloads.

No partitioning. WIndows is on the C drive. I would imagine the partitioning of the drive is as it was when it came from Dell.

Personally, I've been on the PC about 5 times over the past 1.5 years. Its serviceable, not high end, but nothing out of the ordinary for a computer used by non-techies. They are pretty much scared of it, and only do what they are trained to do out of fear of breaking something.

This is the first time I've run into a situation where an applicaiton wouldn't run here.

Not sure how much this helps...but its some more info.

I definately concur it's something with this PC.

I still lean towards the management of dependencies between the 2 files that fixed the problem and versioning of them compared to each other. Unfortunately, I did not have my dad make a backup copy of the 2 DLL's before overwriting them so I do not have access to them to give the older version information.

Me_again · Post by **Me_again** » Tue Apr 29, 2008 10:16 pm

Ah yes, my first rule of PC troubleshooting, if it has Norton installed, shoot it