Printable View
Hi Friedrich
Using that script I emailed you over the weekend, the OSQL commands (lines
217-224) dont work if the installer program has done a reboot & resume.
At the end of installation, if I cancel the reboot and run the same
installer program again, the OSQL commands works.
Any ideas how I can get around this problem, is this some sort of elevation
problem?<g>
BTW its on XP I've noticed this problem havent tested any other OS's yet.
--
--
Cheers
Richard
Hi Richard,
> Using that script I emailed you over the weekend, the OSQL commands (lines
> 217-224) dont work if the installer program has done a reboot & resume.
>
> At the end of installation, if I cancel the reboot and run the same
> installer program again, the OSQL commands works.
>
> Any ideas how I can get around this problem, is this some sort of
> elevation problem?<g>
>
> BTW its on XP I've noticed this problem havent tested any other OS's yet.
The question is, is the OSQL command executed at all?
"Reboot and Resume" does the following (nothing more and nothing less). It
stops the script and writes the Run registry key that contains the name of
the setup program to run when the computer starts. Then it reboots the
system and Windows starts the installer again. The installer has now the
%_SB_RESUME% variable set to 1. Please note that it doesn't resume where it
left off!!!
I would add a "Display Message Box" script command one line before your OSQL
call to see if the code is executed at all.
Does this help?
Friedrich
And please check the values for %_SB_ERRORCODE% and %_SB_RETURNEX% after
execution of one of the OSQL commands. Perhaps this gives us more
information.
Friedrich
Hi Friedrich
I'm currently install W7 64 on my host machine (clean install not upgrade)
and have just upgraded to VMware 7 as well to try to eliminate those crashes
I mentioned previously during or after compile in SB7. I'll change the
script to check for errors for the OSQL commands later on today, but in
answer to your previous post, none of the OSQL commands are running if the
system has rebooted but do work if I immediately run the install program
again without a reboot.
I'll let you know how I get on.<g>
Cheers
Richard
Hi Richard,
> I'm currently install W7 64 on my host machine (clean install not upgrade)
> and have just upgraded to VMware 7 as well to try to eliminate those
> crashes I mentioned previously during or after compile in SB7. I'll change
> the script to check for errors for the OSQL commands later on today, but
> in answer to your previous post, none of the OSQL commands are running if
> the system has rebooted but do work if I immediately run the install
> program again without a reboot.
>
> I'll let you know how I get on.<g>
Okay :)
BTW, I noticed two things:
1. You do not have defined a Default Directory for your OSQL calls. I would
suggest to set the default directory to see if this makes a difference.
2. (has nothing to do with this problem) You have hard-coded "C:\Program
Files". This will cause problems if the Program Files folder is not named
C:\Program Files <g>.
Friedrich
You mean... he might get "eighty-sixed" ?? <G>
> This will cause problems if the Program Files folder is not named
> C:\Program Files <g>.
>
> Friedrich
>
Jane Fleming
>
> You mean... he might get "eighty-sixed" ?? <G>
>
Exactly <g>
Friedrich
yuk yuk yuk
Jeff Slarve
Hi Friedrich
I think I've found the problem and have attached an example script to show
the problem.<g>
I've taken your advice and added in some lines to trap for the errorcodes
and returnex code and am using the CSIDL program files in my main script as
well. <g>
Basically if the window is hidden then it doesnt work, but if its not hidden
then it works even though its identical code.<g>
I havent tested this on anything other than XP at the moment, but to test
this you'll need an XP 32bit instance and then install these updates from MS
in the order shown.
http://download.microsoft.com/downlo...tfx35setup.exe
http://download.microsoft.com/downlo...v2-x86-ENU.exe
http://download.microsoft.com/downlo...288-v3-x86.exe
Then you will need to install MS SQL 2008 Express, you've got a fairly up to
date copy of the script so you can see whats going on in more detail if you
need it. <g>
Then run the attached script. You will get an Error of 1 for the SBErrorcode
for the hidden window and no db will be created, but the unhidden window
will work.
Now I know I could for a workaround run the windows unhidden but these OSQL
commands are being used as a workaround to installing the SQL script on the
users machine, running it then deleting it as I dont want the user to know
what the username & passwords are to gain access to the db.
I've also sent you an email privately as well.<g>
Cheers
Richard
Hi Richard,
> Basically if the window is hidden then it doesnt work, but if its not
> hidden then it works even though its identical code.<g>
I fear there is nothing that I can do to help :-( If you are using
ShellExecuteEx to run OSQL "hidden", then the nShow fMask is set to SW_HIDE.
Nothing more or less.
http://msdn.microsoft.com/en-us/libr...84(VS.85).aspx
Perhaps this is a bug in OSQL? I don't know. What you can try is to use
CreateProcess instead of ShellExecuteEx (unmark the "Use ShellExecuteEx
option in your "Run Program" function). Does this give a different result?
Friedrich