Jim Lawrence
accessd at shaw.ca
Sat Feb 21 12:11:49 CST 2015
The local and provincial government's IT departments, back in the late '90s, gave an edict that there could be no DAO databases...I guess too much important data was lost over the years since the early '90s. I for one was pleased to hear this turn of events as it tended to stop the proliferation of these really badly designed projects and with every data loss, it was another nail in the MS Access coffin. Unfortunately, this rule came too late and I believe was one of the major factors that removed MS Access development from the business world. Considering that ADO IDE database connections, design and a good SQL DB BE, would have solved the problems right from the getgo. I believe if MS had been so inclined MS Access still would have been a major player within offices...an opportunity lost, IMHO. Jim ----- Original Message ----- From: "Tina Norris Fields" <tinanfields at torchlake.com> To: "Access Developers discussion and problem solving" <accessd at databaseadvisors.com> Sent: Saturday, February 21, 2015 6:45:15 AM Subject: Re: [AccessD] Backend database corruption Absolutely - loss of connection while writing - go boom. Also, transmitting data between different OSs. That experience happened here a good ten years or more ago - Win 98 and Win XP and Win 2K machines sharing a database. Different kinds of NICs (at least one doing a self-check periodically, breaking connection for the self-check), different Oss, and the Access databases being used simply got fried. At the playhouse, it was one database. At a publishing house, it was five databases before the issue got figured out. TNF Tina Norris Fields tinanfields-at-torchlake-dot-com 231-322-2787 On 2/19/2015 4:06 PM, John W. Colby wrote: > 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 > > On 2/19/2015 3:01 PM, Janet Erbach wrote: >> Hello! >> >> It's been years since I've addressed this group, so please be patient >> with >> me while I get back into the swing of this. >> >> I've been an Access developer for the last 15 years or so. Until >> recently >> I created straightforward apps used on a small group of hardwired >> networked >> computers that had 5 or 6 users in the app at the same time. >> >> Last year I took a job with a large manufacturing plant, and just >> deployed >> a very complex app that I co-wrote with one of the access-fluent >> production >> supervisors. It is supposed to run non-stop on 20+ machines, all >> with WIFI >> connections. It writes machine production data to a set of front-end >> tables; every 15 minutes the app checks to see if there is network >> connectivity - if there is, the front-end table data is posted to the >> back-end tables on the network, the front-end tables are emptied, and >> the >> loop begins again. >> >> The app worked pretty well when it was running on one or two >> machines. Now >> that it's up on 20 machines, the back end is corrupting multiple times >> during the day - which, of course, brings the whole show to a halt. The >> error log seems to indicate that loss of a network connection during the >> back-end write operation proceeds the corruption. >> >> I have two questions. Will hard wiring the network connection to these >> machines go a long way towards stopping the corruption? Is there >> anything >> else that could be contributing to this that I need to be aware of? >> >> Thank you for your help. >> >> Janet Erbach > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com