Checking that a table has copied correctly

[Bryan - Gendev]

In my application I copy an 'altered' table to a folder with the same tablename as the original 'master' table.

To provide a check that this has been accomplished successfully I:-

1 delete the 'master' table
2 copy the 'altered' table as the master
3 Use an API (below) to compare the file time of the dbf and the fpt copied files.

Declare Integer CompareFileTime In kernel32;
STRING lpFileTime1, String lpFileTime2

This is a too exact comparison, as when making a vidoe for the Help files the operation returns a fail due to a slight time lag.

Is there a better way of confirming that the replacement has taken place correctly.

I use the same procedure if the user wishes to revert to the original and loose the changes.

Thanks for any clues.

GenDev

 

[Mike Lewis]

An easy way of doing this would be to use FDATE() to get the timestamp of each of the files in question. Pass 1 as the second parameter. For example:

ltTime1 = FDATE("c:\data\mytable.dbf", 1)

Then compare the two timestamps, allowing for a pre-determined margin of error:

ltTime1 = FDATE("c:\data\mytable.dbf", 1)
ltTime2 = FDATE("c:\data\myothertable.dbf", 1)
IF ABS(ltTime1 - ltTime2) < 60
  ? "Files are OK"
ENDIF

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

I wonder if the file time would be a good measurement or indicator of a replacement having taken place.

You could instead check some assertions in betwwen steps:

In step 1b) you could rather check, whether the original table really has been deleted by checking with FILE() or better ADIR() (as FILE() might report some file compiled into your exe and ADIR does check on hdd only). Check if ADIR(aDummy,Filename) returns 0.

In step 2b) you could check, whether the new file has arrived again with ADIR(), this time check it returns 1.

And instead of your step 3 you could also check the file length and if you want to be really sure, compute a checksum of the file, eg an MD5 value and compare the new master MD5 value(s) with the MD5 checksum of it's origin file(s).

Bye, Olaf.

 

[Mike Lewis]

Olaf has made a good point. I was going to suggest calculating a checksum of the entire file. However, these are DBF files, and it's possible that the update date in DBF header (bytes 1 to 3) would be different in each case (not sure about that). If so, you would have to disregard those bytes when calculating the checksum.

I also wonder whether you really need such a stringent check. I would have thought that, if the copy didn't exist before, and it does exist now, that would be a good indication that the copying process has succeeded.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

Well Mike,

just looking at before and after there is and will be master.dbf/cdx/fpt files. The point is still valid, as you can check after both deletion and copy step, if the old file was deleted and the new file is there afterwards.

That is my suggestion of steps 1b and 2b would also ensure you have replaced the table, even without any further step 3 / Checksum testing.

Bye, Olaf.

 

[Bryan - Gendev]

Mike,

Picking up your idea of checking the header of the file for the update date - is there any code to do that. That would confirm the original table is back in place when I revert.

One question - will the update date be affected when I do the file copy of the original back from the backup?

Thanks

GenDev

 

[Bryan - Gendev]

Sorry I should have looked at the FAQ


How to read a DBF Header and get info about it
faq184-3162

gendev

 

[Olaf Doschke]

gendev, you copy the file content, it is not changed by that, the date within the dbf header is only changed by vfp, but not with it's COPY command.

It's still a weak indicator of what file you have. It's much easier to do FILE() or ADIR() checks after delete and copy in my oppinion, you know where you copy from, you know where you copy to, the only thing that could go wrong is that you can't delete the file, while it is in use, so checking it really is deleted is the main check you need to ensure has been done. If you also want to check the copy was complete and wasn't interrupted and the whole file was copied, a checksum is a better choice. Only checking a date within the header only ensures the header was copied.

Bye, Olaf.

 

[Mike Lewis]

Gendev,

I was not suggesting that you compare the dates in the header. I was suggesting that you compare the checksums of the entire file contents.

Something like this:

lcCheck1 = SYS(2007, FILETOSTR("File1.DBF"))
lcCheck2 = SYS(2007, FILETOSTR("File2.DBF"))
IF lcCheck1 = lcCheck2
  * Files are the same
ELSE
  * Files are different
ENDIF

If the check succeeds, you can be pretty sure that it's the same file.

The point about the date in the header was that these might be different, and that would upset the comparison. However, Olaf says that I was wrong about that, so the above code should give you the result you want.

Note that this method might be a little slower than checking the timestamps, and it won't be suitable if the file is very large (it won't work if it's more than 16 MB).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

Another idea:

While Foxpros Commands like COPY FILE and ERASE don
t report back, if they fully succeded, you can use Windows API functions, which do so:

DeleteFile:

http://msdn.microsoft.com/en-us/library/aa363915(VS.85).aspx

CopyFile:

http://msdn.microsoft.com/en-us/library/aa363851(VS.85).aspx

Both have a return vlaue indicating success or an error.

Bye, Olaf.

 

[Bryan - Gendev]

Thanks Mike and Olaf for your further suggestions.

I will never know how large the users specific table is so I guess I can't use the checksum method.

I have implemented the delete checking and success = copyfile so I should be confident of the revert succeeding.

It is very important for the user to be sure the original file is in place as it is a vital part of a large 3rd party application.

So all checks are IMHO valid and good.

Regards
GenDev

 

[Olaf Doschke]

Ok, gendev, sounds fine.

In reagard to file size problem of computing the checksum of large files: It would be significant enough, if you check eg the first 8K and the whole file, if smaller, you can eg read in 8K via FREAD().

This includes the header, so changes in reccount, last update time and of course structural changes, which are reflected in the dbf header and thus surely change the checksum. I'm not so sure about FPT and CDX though. But like you say, all checks are valid, as they raise the confidence.

Bye, Olaf.

 

[Mike Lewis]

GenDev,

The approach you have decided on sounds good. Glad we were able to help.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy