[AccessD] Dropped records...Boatloads of them

[jack drawbridge]

Stuart,

Regarding the corrupt index --assuming you could identify that was the
issue - could you drop the index and re-index? Not sure how you would
determine the index is corrupt,  any ideas?

jack

On Tue, May 26, 2015 at 6:31 PM, James Button <jamesbutton at blueyonder.co.uk>
wrote:

> 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
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>