[AccessD] Shelling to a batch file

I've never had much luck with doEvents in our Terminal Services environment.  For example, I used it tu update the status bar when processing a number of files (say 100 invoice Word docs) that are written in sequence as a recordset is traversed.  Generally the status bar shows progress nicely on a PC but just sort of stays put on our thin clients even with DoEvents.  Polling in a loop is the kind of thing that I always worried would get me into trouble in a multi user environment.

 

An example where shellWait shines is when I need to move a block of files into place and need to be sure that they are there before processing them.  Our estimating data is housed in a header file, a sub folder and then 65 odd files in the sub folder and then there may be additional sub foldlers.  That's the way of Pervasive data.  I have a choice of  creating an ODBC link to the file structure wherever it is or moving the files into an existing linked location and name them according to what the Access link expects.

 

I used to do this using an API filecopy routine with an overwrite parameter by building arrays of file names using the DIR function and then creating the folders and copy/naming the files into the existing ODBC location.  The process ran synchronously so the code that worked with the data in situ completed before processing the Pervasive data proceeded.

 

By the way, moving the files is at least 30 times faster than creating the link on the fly.

 

All that was replaced by a single call to shellWait calling Robocopy.exe (and then Name twice).

 

Different strokes. 

Ciao Jürgen Welz Edmonton, Alberta jwelz at hotmail.com


 
> From: jimdettman at verizon.net
> To: accessd at databaseadvisors.com
> Date: Sat, 6 Mar 2010 06:51:57 -0500
> Subject: Re: [AccessD] Shelling to a batch file
> 
> Max,
> 
> <<Is there any value in one over the other do you think?>>
> 
> There is a difference. Your code uses the WaitForSingleObject API call,
> which pauses execution in VBA until the watched process moves into a
> signaled state (it releases all its threads).
> 
> With my code, I'm just checking the status of a given process and code
> execution continues. So I loop and issue a DoEvents.
> 
> I've never really used the capability, but I originally had intended to
> but in some type of animation/status notification, so I wanted code
> execution to continue.
> 
> As for Stuart's point that it is a little extra work each time I use it, I
> suppose that's true, but then I'm not always using it to monitor a shelled
> process, so I keep the check separate.
> 
> In general, I like to keep my building blocks of code as minimal as
> possible and combine when needed. 
> 
> I suppose I could easily do a ShellWait() type of thing, but then I would
> be repeating code I already have somewhere else and now I've got another
> procedure. Seems a lot simpler and more straight forward to me this way.
> 
> Jim.
 		 	   		  
_________________________________________________________________
IM on the go with Messenger on your phone
http://go.microsoft.com/?linkid=9712960