Does SHELL needs Administrative privileges depending on the OS versio? 1

[wakkara]

Hi there!

I have a Applicaction that uses as DB Engine MySQL, y use mysqldump.exe to Backup and MySql.exe to restore the DB.

I use Shell to run the EXEs which works great on (Vista 64), (Win 7 x86) Both with VB6 installed.

The Code I use to Restore:

Shell("cmd.exe /c " & Chr(34) & App.Path & "\MySql.exe" & Chr(34) & " -u root --password=12345678 --host=localhost --port=3306 --default-character-set=latin1 MyDataBase < " & Chr(34) & App.Path & "\" & strNameFile & Chr(34), vbNormalFocus)

UNTIL I install the program on a clean (Win 7 64) OS.

It just simply wont run the EXEs from my application, I have deduced that has to do some how with Administrative Privileges because
- I have tried to run EXEs from CMD directly without "As Adminsitrator" and is not working.
- But if i run it "As Adminsitrator" it works Great.

The Compiled EXE has being ran as Administrator and still not working.

What do you think it could be?

Thanks

 

[dilettante]

I don't know how you ever got this working anywhere.

Most likely your problem stems from using read/write data under App.Path, which is probably in a protected filesystem location. Maybe you had this working on some systems because you tested it without doing an install? Or somebody screwed around and hacked up UAC settings?

Are you positive these EXEs don't run? Or are they running but not finding the database?

It might help to know where these files are installed, how they were installed (just copying files is not installing), whether all of this was done under the same user, what ended up in the user's VirtualStore, etc.

Also note that Program Files is not really Program Files for a 32-bit program on a 64-bit Windows system. These go into Program Files (x86).

 

[wakkara]

Thanks for the response dilettante.

I think i know where the problem is:

After changing
Shell("cmd.exe /c .... (The /c Stands for Closing Window i Think)
for
Shell("cmd.exe /k ... (The /k Stands for Keep Window i Think)
So I could really see the error and the error is

'C:\Program' is not recognized command.....
So the problem relies on the separation of on the word Program Files (x86). But its funny cuase i used Chr(34) to enclose the paths in case there is a separation like that, But apparently when sending that to Shell it interprets it as a Single Quote

and

I tried this

Shell("cmd.exe /k """ & App.Path & "\MySql.exe" & """ -u root --password=123456 --host=localhost --port=3306 --default-character-set=latin1 MyDataBase < """ & App.Path & "\" & strNameFile & """", vbNormalFocus)

And Still the same problem.

i have tried the same installation with insallshield on the other 2 OS and there is no such problem.

Now i know is not privileges, its how the quotes are interpreted on this OS which i have to say.... The OS in which is not working is in english, and the ones are working are in Spanish.

 

[dilettante]

Well I looked into the " vs. ' issue and I think that might be a red herring. The use of ' in the error message was probably just a poor choice on their part, or in any case misleading.


No, I think what is biting you here could be the ( and ) characters in the diretory level name "Program Files (x86)" instead.

Start a command prompt, then type "cmd /?" without the quotes and read the help text that results. The rules for how " characters in the command string get processed can vary based on a few factors, one of them being the presence of any characters from the list:

&<>()@^|

You almost need another pair of quotes around all of your command line following the /k switch. The result would look sort of like:

[tt]cmd.exe /k ""C:\Program Files (x86)\MyStuff\prog.exe" -abc -z < "my file.txt""[/tt]

That's shortened from your actual case, but note the funny extra pair of quotes around everything following /k.

 

[wakkara]

Hi dilettante

Well i think you are pointing me pretty close to the error/solution.

Here is what i have discovered

On the Os that are in Spanish the Shell command Opens the cmd prompt on:

C:\Windows\System32
And the OS on English it opens the cmd prompt on the App.path:

C:\Program Files (x86)\MyStuff
So my program is trying to use Full paths
"C:\Program Files (x86)\MyStuff\prog.exe" -abc -z < "my file.txt"

Which is not working when prompt is on
C:\Program Files (x86)\MyStuff\ (Dont know why)


And its working on
C:\Windows\System32

I have tested this way:
When prompt in:
C:\Program Files (x86)\MyStuffI use:
prog.exe -abc -z < "my file.txt"
IT WORKS

When prompt in:
C:\Windows\System32I use:
prog.exe -abc -z < "my file.txt"
which Wont WORK because it needs the full path to the exe.

So i think i have to "cd\" the prompt and use always full path in order to work, But....

How that can be done with Shell?
Or making bat file (Idea Which i don't love ) Will do the trick?


Thanks again

 

[dilettante]

If it opens at [t]]C:\Windows\System32\[/tt] that's pretty weird.

How is the program being started? If from a shortcut (Start Menu or otherwise) perhaps the "Start in" folder is set differently.

But in any case your program can do something like this:

ChDir App.Path
ChDrive App.Path

Do this in Form_Load or just before calling Shell(), etc.

The program's current Dir and Drive should be inherited by the spawned process.