[AccessD] Backend database corruption

Yes, if you do go the CSV rout (or other data file), do yourself a favor 
and perform a line count and checksum which are written into the file.

Better still, just go to SQL Server.  This is free, easy and way 
powerful, and will absolutely prevent the corruption issues.

John W. Colby

On 2/19/2015 4:34 PM, McGillivray, Don wrote:
> And if you go the CSV route, be sure that your app on the server has a means of determining when a CSV is complete and ready for import.  Years ago I built a system that imported data into an Access BE from fixed-width text files produced by automated mail inserting machines.  Each input file would contain tens of thousands of records, and I had to deal with the problem of a large file being "present" in the drop zone but possibly still being written to when detected.  If I remember correctly, I dealt with it by capturing each file's size on either side of a brief interval.  Files that were the same size on both sides of the pause were considered ready, and the others were left for the next import cycle.  I had to experiment a bit to find the appropriate pause interval.  There are probably smarter ways to do this, but it worked . . .
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W. Colby
> Sent: Thursday, February 19, 2015 1:06 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Backend database corruption
>
> Loss of connection while writing to an Access DB is a known issue, never fixed, and probably unfixable.
>
> Don't use Wifi / WAN with an Access BE.
>
> The best option is to move the BE to a SQL Server BE.  That will absolutely solve this issue.  If you must continue to use Access as the BE, then write CSVs to a directory on the server and have an Access app RUNNING ON THE SERVER watch for these CSVs and import them into the table.  At least if the write to the CSV file is interrupted, it does not corrupt the BE.
>
> John W. Colby
>
>