asked on

How to workaround backup routine runtime errors?

Hi Experts!

Few years ago I've gently obtained here a very util backup routine that works well with exception of the fact that frequently some errors occurs when it runs (but it still does the job)

Accordingly with the pictures:

and then

The code:

LOCAL cTempZip, cTempPath, cdia, m.drv
LOCAL oTherm, cThermometer

*-- Close forms
=fecha_forms()


*-- maio 2010 Close work areas
FOR i = 1 TO 100
	SELECT(i)
	use
ENDFOR

cTempZip=""
cTempPath=""

m.drv = m.driver+":"+m.diretor
cSource = ADDBS(m.drv) && This is data path

SET CENTURY on

cdia = DTOC(DATE())
cdia = SUBSTR(CDIA,1,2) + SUBSTR(CDIA,4,2) + SUBSTR(CDIA,7)
*--cDestination = m.drv+cdia+".bak"

cDestination = m.drv+cdia+".zip"

cTempZip = m.drv+'temp'+  '.zip'

cThermometer = 'gsThermometerBar'
oTherm = createobject(cThermometer)
oTherm.lblProgress.caption = "Backup dos dados da Livraria"
oTherm.Show()

DECLARE INTEGER Sleep IN kernel32 INTEGER

IF FILE(cTempZip)
	DELETE FILE (cTempZip)
ENDIF

= STRTOFILE(CHR(80) + CHR(75) + CHR(5) + CHR(6) + REPLICATE(CHR(0),18),cTempZip)

DIMENSION aDBFs(1,5)
nCount = ADIR(aDBFs,cSource+"*.*")
oShell = CREATEOBJECT("Shell.Application")
FOR i = 1 TO nCount

	oTherm.Progress1.Value = INT(i/nCount*100)

	cFileName = aDBFs(i,1)
*--	IF UPPER(RIGHT(cFileName,3)) $ "DBF|FPT" AND NOT ("FOX" $ cFileName)

*-- Fev 2011: Salves .CDX also
	IF UPPER(RIGHT(cFileName,3)) $ "DBF|FPT|CDX" AND NOT ("FOX" $ cFileName)
		oTherm.lblProgress.caption = "Backup => "+ cFileName
		cFile = cSource + cFileName
		nCount1 = oShell.NameSpace(cTempZip).Items.Count
		oShell.NameSpace(cTempZip).CopyHere(cFile)
		DO WHILE oShell.NameSpace(cTempZip).Items.Count = nCount1
			= Sleep(100)
		ENDDO
	ENDIF
ENDFOR

oTherm.Release

RELEASE oShell
COPY FILE (cTempZip) TO (cDestination)
DELETE FILE (cTempZip)
CLEAR DLLS

*-- Find where is the pen drive
IF DISKSPACE("E:\") = -1
	IF DISKSPACE("F:\") = -1
		IF DISKSPACE("G:\") = -1
			IF DISKSPACE("H:\") = -1
				MESSAGEBOX("Não há dispositivo de gravação (pen-drive) disponível para salvar os dados !",48,"Erro")
			ELSE
				lcdrive="H:\"
				COPY FILE &cDestination TO &lcdrive
			ENDIF
		ELSE
			lcdrive="G:\"
			COPY FILE &cDestination TO &lcdrive
		ENDIF
	ELSE
		lcdrive="F:\"
		COPY FILE &cDestination TO &lcdrive
	ENDIF
ELSE
	lcdrive="E:\"
	COPY FILE &cDestination TO &lcdrive
ENDIF

*-- Reabre as áreas fechadas para backup

*-- Some clean-up routines

*----------
=montadic()
*----------

*--- Monta os dicion rios de integridades
*----------

=mont_del()

=mont_atr()
*----------

* Ativa o Help
*******
Do Help
*******

*-- reativa toolbar
fotb   = CREATEOBJECT("cls_toolbar")
fotb.show()

return

Open in new window

Could you point a workaround to that?

Thanks in advance!

Olaf Doschke

That's a weird error, but it seems it has to do with the asynchronous nature ot zipping via Shell.Application and waiting for the end of it with the DO WHILE..ENDDO loop.
The item count of the Namespace object increments, while you move files from to a ZIP archive. It seems in seldom cases you catch the process, while the ZIP file is replaced by the next version including the next file, and then even the Namespace object itself does not exist. So you have to handle that case, that error.

Do While .T.
   Try
      nCurrentCount = oShell.NameSpace(cTempZip).Items.Count
      If nCurrentCount>nCount1
         Exit
      EndIf
    Catch
      *
    EndTry
    = Sleep(100)
Enddo

Open in new window

This makes the assumption, that the ZIP does not exist for a short time period. I don't know for sure, but I know Winzip and other zip routines, most probably also the zip functionality of Windows itself, use a temp dir and temp file to zip, and so the result of adding a file to a zip is created in TEMP and then the old zip file is replaced. And if you exactly hit the point in time that happens, Namespace(cTempZip) does not exist, as the cTempZip file is replaced in that moment.

Anyway, independant if that's right or not, the CATCH block will catch the error you report and in that case do nothing. Next loop will then most probably refind cTempZip and the current count will be incremented, so the loop ends.

The next error then is a follow up, I don't have any idea why the temporary missing Namespace object would cause that, but I assume you will never see that error again, if you catch the first one, it's just a follow up error.

Bye, Olaf.

ASKER CERTIFIED SOLUTION