[AccessD] Unzip Files

ShellAndWait  by Terry Kreft

http://www.mvps.org/access/api/api0004.htm

Randy Birch has some variations on this to avoid loops, possible screen 
freezes etc.

http://vbnet.mvps.org/
Search on Shell and Wait
or
http://vbnet.mvps.org/code/faq/waitforsingleobject2.htm

Hale, Jim wrote:

><Then I would shell (and wait) to a command line>
>how do you pause Access so that it waits until the process is finished? I
>have a process that creates and runs cmd and bat files and then destroys
>them. I have to pause Access so that the files are run before Access kills
>them. My current method is a kludge. In Excel I use the Wait function. Is
>there an analogous function in Access? TIA
>Jim Hale
>
>-----Original Message-----
>From: DWUTKA at marlow.com [mailto:DWUTKA at marlow.com]
>Sent: Wednesday, April 27, 2005 5:18 PM
>To: accessd at databaseadvisors.com
>Subject: RE: [AccessD] Unzip Files
>
>
>Sorry for the delay.....but I've been a little swamped during this thread.
>Ironically, I am rebuilding an application that 'auto' extracts files from
>zips.  It's probably more complex then what you are looking for though. 
>
>I host a realty website (remax realtors).  It has a ton of properties, which
>are updated regularly.  The updates are posted to an FTP site, and are
>zipped.  The zip files contain both delimited text files with the property
>information, and .jpg files with images for the property.
>
>My original application used the INet control in VB, to download the files
>to a directory.  Then I would shell (and wait) to a command line that
>unzipped all of the files to that folder.  That was actually pretty easy to
>do. The REAL fun part was then to extract all of the information from the
>unzipped text files, update the database, and then sort all the pictures
>(and create thumbnails for them).  The only trick on the first part was the
>unzipping.  I found and Add-on for WinZip, which works perfectly, but the
>only catch is that you have to have a registered version of WinZip for it to
>truly work automated.  If it's not registered, the command line prompts you
>for things...which is a little quirky for an 'automated' system.  So I
>splurged on the $29 to register WinZip.  It was money well spent.  The
>command line works wonderfully, and better yet, the registered version of
>WinZip has a lot of neat features to use.
>
>The reason I am rebuilding this application, is because I spent the last few
>weeks rebuilding my home network.  Now that I have everything setup at home
>(almost), I want to improve this process.  It's downloading about 1.5 gigs
>worth of zip files, which even over my 3 megabit connection, takes a while.
>Then it unzips them (which can take just as long, or longer), then it runs
>the 'update' process.  During the download, doing anything on my own crawls
>to dialup speed sometimes.  During the rest, that server is pretty tied up.
>I decided to change the download/unzip process, and also modify the update
>process, so that my customers will be able to track what has been updated.
>In the download/unzip phase, I was using the INet control, which is quirky,
>and the way I had it setup, I knew what file was downloading, but not how
>big it was, or how fast it was downloading, and I couldn't pause it, only
>kill the whole process.  So the new process (which I have the dl/unzip phase
>done, working on the new update process) downloads everything using API
>calls, and not only shows the file size, but how much has been downloaded
>and even has pause and cancel buttons. (Can't pause it forever, because the
>FTP site will time out, but I'm going to fix that too.....).  So now, if I
>want to use the net at high speeds, when this thing is running, I can just
>go to the server, and pause the process.  I also made a modification to the
>zip process.  Instead of one big unzip '*.zip' command line, I have the VB
>program start a new thread, and that thread starts runs the unzip process
>for one zip file.  Works like a charm.  (It's all event driven too, so when
>the last zip thread is done, it raises an event the main process can use to
>launch the update process).
>
>Drew
>
>***********************************************************************
>The information transmitted is intended solely for the individual or
>entity to which it is addressed and may contain confidential and/or
>privileged material. Any review, retransmission, dissemination or
>other use of or taking action in reliance upon this information by
>persons or entities other than the intended recipient is prohibited.
>If you have received this email in error please contact the sender and
>delete the material from any computer. As a recipient of this email,
>you are responsible for screening its contents and the contents of any
>attachments for the presence of viruses. No liability is accepted for
>any damages caused by any virus transmitted by this email.
>
>------------------------------------------------------------------------
>
>No virus found in this incoming message.
>Checked by AVG Anti-Virus.
>Version: 7.0.308 / Virus Database: 266.10.4 - Release Date: 27/04/2005
>  
>

-- 
Marty Connelly
Victoria, B.C.
Canada