[AccessD] Dropped records...Boatloads of them
James Button
jamesbutton at blueyonder.co.uk
Tue May 26 17:31:46 CDT 2015
Yes -
Basic premise has to be that the system will fail to properly process actions on
any multi-access database, and especially a distributed one - where the update
(insert modify and delete) actions are apparently performed by programs running
on attached devices.
So that means fault tolerance with confirmation of actions on the data verified
after any change -
As in terminate the updating transaction connection (but not necessarily the
actual LAN/WAN connection) and then re-access the server store to validate the
update actually occurred.
On the basis that you should
Have an audit log.
And a re-do updates facility to bring a backup save up-to-date.
Then it is probably easier to have update actions passed back to the BE/server
for that to action the updates, and then pass out a confirmation that the update
request entry has been:
Recorded on the redo store queue.
Recorded on the audit log.
And the update entry has been actioned. - as in from the B/E facility
"Coo-ee remote program":- See, here is a re-extract (data, including the audit
detail and deleted status) from the new dataset.
UPS and hard-wired will reduce the frequency of problems - but you still need to
code for the possibility.
(Sort of like having your valuables in a vault - with guards and all sorts of
alarm systems - not truly effective unless the guards can actually - physically
check the vault, and somebody can get the police to turn up and check properly
when the alarms have gone off. See UK news re. Hatton Garden.)
JimB
-----Original Message-----
From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim
Lawrence
Sent: Tuesday, May 26, 2015 10:30 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Dropped records...Boatloads of them
Bingo... :-)
Jim
----- Original Message -----
From: "Stuart McLachlan" <stuart at lexacorp.com.pg>
To: "Access Developers discussion and problem solving"
<accessd at databaseadvisors.com>
Sent: Tuesday, May 26, 2015 2:13:26 PM
Subject: Re: [AccessD] Dropped records...Boatloads of them
The only solution other than hardening your network connectivity is to change
your BE to a
proper RDBMS Server (SQL Server, MySQL or whatever) with fault tolerance built
in.
--
Stuart
On 26 May 2015 at 16:03, Janet Erbach wrote:
> Wow. So are there any other solutions besides:
>
> 1) hardwire the network connections
> 2) install UPS at each workstation
>
> Both of which are due to be scheduled for the 12th of Never...
>
> On Tue, May 26, 2015 at 3:48 PM, Stuart McLachlan
> <stuart at lexacorp.com.pg> wrote:
>
> > Yes, that can happen through a dropped connection when data is
> > being written. I've seen uit happen occasionally.
> >
> > You get a corrupt index. The data is still there, but Access can't
> > find it.
> >
> >
> >
> > On 26 May 2015 at 14:35, Janet Erbach wrote:
> >
> > > Hello all -
> > >
> > > I've corresponded with you all in the last couple of months about
> > > records dropping from an access database in a manufacturing
> > > environment. About once a week we'd find 1-2 dropped records in a
> > > tool crib database. We installed UPS's in the area where this
> > > was happening and...fingers crossed...so far so good. No dropped
> > > records since they went in 3 weeks ago.
> > >
> > > Today I learned that a manufacturing scrap database was missing
> > > records, too. 868,105 records to be exact: All records from 2014
> > > and several months worth from 2015. Thankfully I was able to
> > > restore them from a shadow copy.
> > >
> > > The likelihood of an end-user deleting all that data manually is
> > > so slim that I don't even consider it a possibility. Can a noisy
> > > wireless network environment and/or power brown-outs cause such a
> > > large chunk of data to go missing like that?
> > >
> > > Janet Erbach
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> >
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
More information about the AccessD
mailing list