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?