Updating real time between two or more users

[Guest]

Is it possible to update the information in the code between two or more
users at the same time? I have a counter in the software that I would like to
keep updated per a certain button click. Right now, however, when two or more
users have the database open at the same time, the counter updates
independently in one instances of the access database than the others. So if
it's at 1200 and three people open the database, when they click on the
button that causes the counter to increment, it goes to 1201 for all of them,
instead of 1201, 1202, and 1203. Is there a way to fix this in the code,
short of creating a table and making the "counter" pull the last number from
the table, increment it by one, and place it back into the table where it
will have to be accessed again?

-TIA

 

[Marshall Barton]

Is it possible to update the information in the code between two or more
users at the same time? I have a counter in the software that I would like to
keep updated per a certain button click. Right now, however, when two or more
users have the database open at the same time, the counter updates
independently in one instances of the access database than the others. So if
it's at 1200 and three people open the database, when they click on the
button that causes the counter to increment, it goes to 1201 for all of them,
instead of 1201, 1202, and 1203. Is there a way to fix this in the code,
short of creating a table and making the "counter" pull the last number from
the table, increment it by one, and place it back into the table where it
will have to be accessed again?

It is possible using some kind of robust locking locking
mechanism, but, in the abstract, a very complex process.

In some restricted environments (e.g a field in an Access
table) there are many features that make this a reasonable
exercise.

If you'd be willing to describe your specific situation,
maybe we can suggest a better way to approach your
question.

 

[Ron2006]

If you create that table,
have a form bound to that table, that field,
and open that form as acHidden as a function of the on open of your
main menu form,

Then pressing the button on any form will simply have to do the
following

Forms![HiddenFormNmae]![OfficalCountFieldName] =
Forms![HiddenFormNmae]![OfficalCountFieldName] + 1


And the souce for the display of the official count will have as its
source

=Forms![HiddenFormNmae]![OfficalCountFieldName]


Nothing really hard about that.

Besides that way you have a table open all the time and this can speed
up you overall processing because a connection to the tables mdb is
always present. This is one of the suggestions for speeding up split
mdbs.

Ron

 

[Marshall Barton]

If you create that table,
have a form bound to that table, that field,
and open that form as acHidden as a function of the on open of your
main menu form,

Then pressing the button on any form will simply have to do the
following

Forms![HiddenFormNmae]![OfficalCountFieldName] =
Forms![HiddenFormNmae]![OfficalCountFieldName] + 1


And the souce for the display of the official count will have as its
source

=Forms![HiddenFormNmae]![OfficalCountFieldName]


Nothing really hard about that.

Besides that way you have a table open all the time and this can speed
up you overall processing because a connection to the tables mdb is
always present. This is one of the suggestions for speeding up split
mdbs.

Ron, setting a bound control on a form does not prevent
another user from retrieving the original value. Once the
record is saved the new value will become available, but
there is a potentially large time lag (out to lunch) between
getting the old value and saving the record.

Fetching the old value, incrementing it and saving it back
to its table really should be an atomic operation. This can
be accomplished by opening a recordset exclusively and
performing the increment and same as quickly as possible so
other users are not locked out any longer than necessary.
Of course, a retry mechanism is still needed just for those
rare cases where two users are doing this essentially
simultaneously.

In practice, it is usually sufficient to fetch, increment
and save all in the form's BeforeUpdate event without a lot
of worry about the locking and retry stuff.

Until the OP explains the specific situation, we don't even
know if a form is being used so all this may not apply.

 

[Ron2006]

Thanks for the update. I have not had that problem, which only means I
have not encountered it yet.

Thanks again.

Ron

 

[eos]

AUTO-REPLY From George Levitt

Please allow this to confirm a system receipt of your e-mail.

I am out of the office until Wednesday morning (1/12/05) and will not be
reviewing or responding to email or voicemail until that time.

I look forward to replying to your message on Wednesday.

Thanks and warmest regards, George

 

[eos]

AUTO-REPLY From George Levitt

Please allow this to confirm a system receipt of your e-mail.

I am out of the office until Wednesday morning (1/12/05) and will not be
reviewing or responding to email or voicemail until that time.

I look forward to replying to your message on Wednesday.

Thanks and warmest regards, George