Script won't work for Other Users

[jaeger52]

Hello all,

I have been running into a problem consistently for months now, and haven't been able to come up with a solution. I have a script (I can post code if that helps, but the code doesn't seem to be the problem) that my organization needs to run daily. We are a small office so we want to have the ability people for multiple users to run the process in case somebody goes on vacation, gets sick, or what have you.

I wrote the script, and after the usual testing and implementation process it runs just fine for me. It is a click-and-forget item, and the fact that I can run it successfully tells me the code itself is not the problem. There are sometimes network-induced problems- loss of connection, timeout and the like- but the script is solid. I run the process every day on a VM which is hosted on our organization's network. My coworker has access to this VM and regularly uses it as well. When he attempts to run the script, from the same place using the same process at the same time on the same VM, it fails. The script hangs without explanation, and will sit there until the user prompts action- usually by manually shifting window focus or similar means.

Does anyone have an idea of why this would be? Is this a Windows issue (we run Windows 7), or maybe an issue with his account? Any help or ideas the community can offer would be greatly appreciated.

[JLogan3o13]

4 minutes ago, jaeger52 said:

(I can post code if that helps, but the code doesn't seem to be the problem)

@jaeger52 posting the code always helps, how is anyone to be expected to assist you if they can't see what you're doing?

Edited June 22, 2016 by JLogan3o13

[jaeger52]

Here's the first chunk of the code. There's quite a bit more, but it doesn't even get past this.

expandcollapse popup

#include <MsgBoxConstants.au3>

MsgBox ( $MB_OK, "Startup Successful", "The Daily Process has been successfully launched." )
Sleep ( 18000000 )
Send ( "{LWin}" )
Sleep ( 2000 )
Send ("R:\ADS Daily Processes\ADSDP.accdb /x 01-ADSDP-00-Master") ;Stage 1: ADSDP Launch
Sleep ( 2000 )
Send ( "{ENTER}" )
WinWaitActive ( "Oracle ODBC Driver Connect" )
Sleep ( 2000 )
ControlFocus ( "Oracle ODBC Driver Connect", "", 111 )
Sleep ( 2000 )
Send ( "{CTRLDOWN}" )
Send ( "{A}" )
Send ( "{CTRLUP}" )
Send ( "{DEL}" )
Sleep ( 2000 )
Send ( "PROD" )
Sleep ( 2000 )
ControlFocus ( "Oracle ODBC Driver Connect", "", 131 )
Sleep ( 2000 )
Send ( "{CTRLDOWN}" )
Send ( "{A}" )
Send ( "{CTRLUP}" )
Send ( "{DEL}" )
Send ( "Username" )
Sleep ( 2000 )
ControlFocus ( "Oracle ODBC Driver Connect", "", 141 )
Sleep ( 2000 )
Send ( "{CTRLDOWN}" )
Send ( "{A}" )
Send ( "{CTRLUP}" )
Send ( "{DEL}" )
Send ( "Password" )
Sleep ( 2000 )
ControlClick ( "Oracle ODBC Driver Connect", "OK", 1 )
WinWaitClose ( "Access - ADSDP : Database- R:\ADS Daily Processes\ADSDP.accdb (Access 2007 - 2013 file format)" )
Send ( "{LWin}" )
Sleep ( 2000 )
Send ("R:\ADS Daily Processes\ADSDP2.accdb /x ADSDP2-01 Contact Info Daily Update") ;Stage 2: ADSDP2 Launch

 

[JLogan3o13]

So, the first thing you're going to hear from anyone is that you have zero error checking in the script, which makes it nigh impossible to figure out where it is failing. Does it successfully find the "Oracle ODBC Driver Connect" window? Does it successfully click on the OK control? You have a lot of gray area with all the Sleeps and Sends, but you should be able to at least narrow it down to the region that is failing. I would begin by putting the following at the top of your script:

Opt("TryIconDebug", 1)

That way, if the script is hanging somewhere, such as your call to WinWaitActive, you'll be able to tell. From there, I would do what you can to narrow down how far the script gets before it stops (I have to assume you get no error, that it just hangs, since all you stated by way of explanation is "it fails").

[jaeger52]

Thanks for the reply, JLogan. I've plugged that in and I'll have him test it tomorrow night. When I have an update I'll post it!

[mLipok]

I'm just curious:
After the piece of code that will do the job, what do you do next?
Automate gui to retrieve, input, change  data ?

Why you do not do the same directly on the data resource - I mean using ADO.au3  ??
 

Edited June 22, 2016 by mLipok

[jaeger52]

19 hours ago, mLipok said:

I'm just curious:
After the piece of code that will do the job, what do you do next?

After the process is finished, our core data table is up to date and ready to use. This table serves as the basis for all of the reports and questions my department fields. So once the process is done, the data is already where it needs to be. We're a small group with limited funds lol, so MS Access is what we have to work with!

19 hours ago, mLipok said:

Why you do not do the same directly on the data resource - I mean using ADO.au3  ??
 

Can you explain more about what you mean here? I'm not well versed in database work outside of Access. If there's an easier way to do this I'm not sentimental about this script. I'll scrap it and come from a new angle if it works better. Thanks!

[jaeger52]

My coworker attempted to run the script again last night. For once, we got an error  message to work with! Unfortunately, it makes no sense. Here's the message:

Here's why it makes no sense: I write and compile the scripts on a 64-bit system myself, and run them on the same 32-bit system he used, but with no errors. We both use Radmin to connect to the same VM to run the same process. Any reason he would run into a compatibility error and I would not?

[jaeger52]

Recompiling the script on a 32-bit system got rid of that error code on my coworker's computer. The script ran fine up to line 39, the WinWaitClose. It just hung. Not paused in the tray, no errors thrown, no other indications of a problem. Just a failure to send the LWIN key and get the next database open. Anybody have an idea of why that WinWaitClose might be hanging?

[JLogan3o13]

And we are to assume that the window no longer exists? The reasoning behind it hanging at a WinWaitClose, obviously, would be that the window is still present (not visible, necessarily, just that it exists).

[jaeger52]

Thanks for the reply, JLogan. I can only confirm that the window was no longer visible. I don't have access to my coworker's credentials (naturally) and am only able to work with what he reports, or what I observe on the rare occasions we are both free to work together. The fact that it is a remote process set to run overnight also makes observation a problem. I do try to run trials during the day, but network traffic is too high and it errors out. I am setting up Access to close itself with "QuitAccess" and the "Exit" option now, rather than the "RunMenuAction" and "Exit" option I've been using. As you rightly point out, this appears to be a problem of the window somehow still existing after being told to close and no longer being visible.  This doesn't explain why there is an issue on my coworker's login and not on mine, but if it addresses the underlying issue of preventing the script from finishing that's what I'm after at the moment. Just bugs me when I can't put my finger on the solution!