Puzzle: Why does backing up a data file require web application shut down?
A customer reported a problem:
Customer has a VB/ASP .NET web app that uses VFP data via the provider. When they do a nightly backup of the VFP data (via a simple .CMD with XCOPY), the web app starts tossing errors as it processes SQL commands. Most prominent is error 41: "Memo file is missing or is invalid."
Customer thinks this is a provider problem. Why? Because when the same scenario is set up using the VFP IDE instead of the provider, there are no errors.
Here is some VBScript code to simulate the web application. It just uses the VFPOleDb Provider to execute a SQL Select from a table with a large memo file (.FPT)
OPTION EXPLICIT
DIM oWS, oConn, oRS, i, thisDir, pauseAtEnd
on error resume next
pauseAtEnd = false
Set oWS = WScript.CreateObject("WScript.Shell")
thisDir = oWS.CurrentDirectory & "\"
Set oWS = Nothing
Wscript.echo "Attach!"
for i = 1 to 5
SET oConn = CREATEOBJECT("adodb.connection")
SET oRS = CREATEOBJECT("adodb.recordset")
oConn.Open("Provider=vfpoledb;Data Source=" & thisDir & "Data")
oRS.Open "SELECT * FROM EMPFREE", oconn, 3, 3, 1
If Err.Number <> 0 Then
Wscript.echo Err.Number, Err.Description
pauseAtEnd = true
exit for
End If
Wscript.echo " Run # " & i & ". Reccount = " & oRS.RecordCount
oRS.Close()
oConn.Close()
SET oRS = NOTHING
SET oConn= NOTHING
NEXT
Wscript.echo "Done!"
if pauseAtEnd then
WScript.Sleep 5000
end if
Save this VBScript code to a file with extension .VBS and run it from Windows Explorer.
While this code is running, run a cmd file called CopyData.cmd that has a single XCOPY command to do the file backup
XCOPY DATA\*.* D:\temp\*.* /y
Make sure you change the paths to something on your machine.
The running VBScript gives an error
---------------------------
Windows Script Host
---------------------------
-2147467259 Memo file d:\test\data\empfree.fpt is missing or is invalid.
---------------------------
OK
---------------------------
BTW, converting the error code to hex à TRANSFORM(-2147467259,"@0x") = 0x80004005, which is defined in “C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\Winerror.h”
#define E_FAIL _HRESULT_TYPEDEF_(0x80004005L)
If you think about it, the XCOPY must open the file exclusively to make a valid copy. If not, the first part of the file could be copied, an application modifies it, then the rest of the file gets copied, perhaps resulting in a corrupt file.
So the question is why does it seem to work in the VFP IDE ?
The VFP IDE repro scenario looked like this:
SET EXCLUSIVE OFF
SET TABLEPROMPT OFF
LOCAL lcThisDir AS STRING
lcThisDir = ADDBS(JUSTPATH(SYS(16)))
CD (lcThisDir)
RUN /n CopyData.cmd
LOCAL oExc AS EXCEPTION
CLEAR
FOR i = 1 TO 10
TRY
SELECT * FROM data\EMPFREE INTO CURSOR FOO
CLOSE DATA ALL
? "Run #" + TRANSFORM(i) + ". Reccount = " + TRANSFORM(_TALLY)
CATCH TO oExc
? oExc.MESSAGE
i = 10
ENDTRY
ENDFOR
?
? "DONE!"
The VFP IDE repro code does not give an error and seems to succeed. Why? Can you spot the issue?
Comments
- Anonymous
August 24, 2005
In my prior post (Puzzle: Why does backing up a data file require web application shut down?) the customer... - Anonymous
February 28, 2008
The comment has been removed - Anonymous
June 12, 2012
The comment has been removed