I'm having a heck of a time consistently performing Windows zipping on a beefy but busy server.

At the top of the function (before a very lengthy select), I'm initializing WIIN32API

lnZipTimeout = 10000
DECLARE INTEGER Sleep IN WIN32API INTEGER nTimeout
oShell = CREATEOBJECT("shell.application")	&& Moved up here to give it time to instantiate

And then afterwards, I'm performing a DOEVENtS and a SLEEP()

DOEVENTS FORCE
Sleep(lnZipTimeout)

And then finally I'm calling the CopyHere shell command

lcSource = lctable
lcZipFileName = FORCEEXT(lcTable,"zip")
STRTOFILE(CHR( 80 )+CHR( 75 )+CHR( 5 )+CHR( 6 )+REPLICATE( CHR(0), 18 ), lcZipFileName)
IF DIRECTORY(lcSource)
	WAIT WINDOW [Ready to zip from directory ] + lcSource TIMEOUT 10
	FOR EACH ofile IN oShell.NameSpace( lcSource ).items
		WAIT WINDOW [Zipping directory ] + lcSource NOWAIT
		= Sleep(1000)
		oShell.NameSpace( lcZipFileName ).copyhere( ofile )
	ENDFOR
ELSE
	WAIT WINDOW [Zipping single file ] + lcSource TIMEOUT 10
	lcSourceFile = JUSTFNAME(lcSource)
	lcSourceFolder = JUSTPATH(lcSource)
	oShell.NameSpace( lcZipFileName ).copyhere(oShell.Namespace(lcSourceFolder).items.Item( lcSourceFile ) )
ENDIF

The errors I'm getting during CopyHere (when the exe crashes) are these two:

05/29/2018 05:34 PM:
   Error number: 1426
   Error message: OLE error code 0x80070008: Not enough storage is available to process this command.
   Line number of error: 153
   Program with error: FRMGOOGLEEXPORT.PREPAREUPLOADCURSOR
05/30/2018 02:53 PM:
   Error number: 1943
   Error message: Member NAMESPACE does not evaluate to an object.
   Line number of error: 148
   Program with error: FRMGOOGLEEXPORT.PREPAREUPLOADCURSOR`

Google lookups indicate that I may not be giving it enough time to instantiate the shell instantiation before doing the CopyHere - but it's delaying by many, many minutes before the copyhere is launched.

Any tips? I'm about ready to use a third party zip program...

Go out and buy new servers!! LOL

Hi Mike!

I have used 7Zip directly from both SQL and Powershell under some pretty harsh conditions with no known issues.

I also use SPS VFPcompression.FLL Lib heavily in VFP without any problems.

Bill

Hey Bill - good to see you're still around.

Strangely, the SPS dll as well as the Chilkat dll display the same issues - making me think it's a server resource issue I haven't been able to pin down. The SPS dll just crashes ungracefully. At least the Windows shell and the Chilkat tools provide some diagnostic info...

Using an async background process with VFP like this is kind of a pain and I would suggest that there are better ways to tackle this.

Web Connection includes the old dynazip libraries and zip functions that use it so that's one option. VFPCompression from Craig Boyd is another, and there are also built-in .NET compression functions that are not to difficult to automate with wwDotnetBridge.

Or also as Bill mentions you can use CreateProcessEx() to execute 7zip (which is redistributable) and wait for execution to complete.

Also if you're using COM collections like this it's always a good idea to explicitly create variables for each of the intermediate objects. This is especially true for collection iteration.

+++ Rick ---

Did you check to see what the paths are when you are crashing? I suspect maybe you're getting the . and .. or folders when the API is expecting files?

+++ Rick ---