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 (3)

  1. In my prior post (Puzzle: Why does backing up a data file require web application shut down?) the customer…

  2. Cetin Basoz says:

    Is this answered somewhere?

    I think, IDE doesn’t error because there is only a filter on table with SQL. In cursor there are just integer values as pointers to memo blocks. The block itself may be invalid but VFP doesn’t know that until it really needs to go and read that block from FPT.

    With VFPOLEDB however it should transfer all data, including memo.

  3. nige sat says:

    pr hape s were difi t2o high brow fur me.

    later i put plug in.

    hi

    me t2o