[AccessD] Handling concurrent updates

[Gustav Brock]

Hi Bill

That’s a good question. The function were created for a scenario where records would never get deleted.

However, it has now been updated to version 1.0.2 with extended error handling in SetEdit to prevent an endless loop in case of other errors than a concurrent edit.

Note please, that the test run will still fail in case that a third process deletes the file, but that is no different than if you had not the concurrent edit/update handler running.

/gustav


Fra: Bill Benson<mailto:bensonforums at gmail.com>
Sendt: 6. februar 2016 07:50
Til: Access Developers discussion and problem solving<mailto:accessd at databaseadvisors.com>
Emne: Re: [AccessD] Handling concurrent updates

I thought that the way to handle concurrent edits in code is based on how
you open the recordset, with locks. In your case, were you to not lock all
the records, what happens if another user comes along and deletes the
record(s) through their code, leaving the item you are attempting to edit
uneditable forever, and you then are in an infinite loop?

Am I missing something obvious (such as that this could never occur or
something)?

On Wed, Feb 3, 2016 at 11:01 AM, Gustav Brock <gustav at cactus.dk> wrote:

> Hi all
>
> If you ever have struggled with this in VBA, you know it's a daunting task
> with a lot of error handling.
>
> For a client, I had to find a smarter method. A bit surprisingly,
> Bing/Google didn't reveal anything useful, so I ended up with two tiny
> functions to handle edit and update.
> With these it takes (net) only one line of additional code. It is all
> described here:
>
>    http://rdsrc.us/BvX5Gw
>
> including a demo app and the small code module with the two functions.
> If you have access to a Northwind database running in an SQL Server
> instance, you can run the test right away. You can also relink to an Access
> database, but that is less fun as the updates are so fast that collisions
> are much fewer.
>
> /gustav