Other Users don't see table updates

[rdemyan via AccessMonster.com]

How does one handle the situation where two different users are looking at
bound forms that display data from a table.

User #1 makes a change to the data, but User #2 is just perusing the data.
User#1 has his bound form updated, but User#2 does not.

In this case User #2 is not seeing the actual current state of the data,
unless he/she does something to cause the data to refresh.

How do developers handle this, if at all?

If it were SQL SERVER as a backend, could one use a trigger on the table to
cause screens to refresh of all users currently viewing data from the table
that was updated.

I haven't given this much thought before, but now I'm wondering how this is
handled.

Thanks.

--
Message posted via http://www.accessmonster.com

[salad]

rdemyan via AccessMonster.com wrote:

How does one handle the situation where two different users are looking at
bound forms that display data from a table.

User #1 makes a change to the data, but User #2 is just perusing the data.
User#1 has his bound form updated, but User#2 does not.

In this case User #2 is not seeing the actual current state of the data,
unless he/she does something to cause the data to refresh.

How do developers handle this, if at all?

If it were SQL SERVER as a backend, could one use a trigger on the table to
cause screens to refresh of all users currently viewing data from the table
that was updated.

I haven't given this much thought before, but now I'm wondering how this is
handled.

Thanks.

I suppose you could put in a timer interval on the form (the value of
the interval in in millisecons so remember 1000 equals 1 second) and
every so often refresh (see Refresh method in help)...maybe Repaint
provides a better description of Refresh in help. Maybe put in a
command button to refresh instead of a timer.

What's happening? Are all of the people sitting at one screen looking
at the same record for extended periods? If I say to Joe Blow, "Hey, go
check out record 1 in the Edit form", and he opened it, he's see what
the values are on my form up to the point of the last save.

Are you sure the person that opened the form first and made changes has
really saved the record?

[david epsom dot com dot au]

Database systems are not real time network communication
services. Where people really want real-time network
communications, they frequently use UDP or TCP over IP.

Where a database is also required, and there are only a
small number of users, people sometimes kludge live
updates by polling the database.

You can speed up the database polling and reduce the
load on the system by using a semaphore table (so the
users poll the semaphore table instead of polling the
data tables).

To get any of this to work, you also need to make
sure that the clients write back to the server in a
timely fashion. This also slows the clients and loads
the server, but again, it is justified in some cases.

Theoretically, you could use SQL Server to send a
network message to other users, but I've never seen
it done that way - normally, if you are going to
write code to send network messages, you can put it on
the clients anyway.

Rarely, people used sql server to send mail messages -
- this was the source of the infamous SQL Server worm
that almost brought down the internet - but that wasn't
really intended for real-time display update either,
because mail messages typically go through a "store and
forward" mail server.

(david)
"rdemyan via AccessMonster.com" <u6836@uwe> wrote in message
news:5d04d2b1ef7c5@uwe...

How does one handle the situation where two different users are looking at
bound forms that display data from a table.

User #1 makes a change to the data, but User #2 is just perusing the data.
User#1 has his bound form updated, but User#2 does not.

In this case User #2 is not seeing the actual current state of the data,
unless he/she does something to cause the data to refresh.

How do developers handle this, if at all?

If it were SQL SERVER as a backend, could one use a trigger on the table
to
cause screens to refresh of all users currently viewing data from the
table
that was updated.

I haven't given this much thought before, but now I'm wondering how this
is
handled.

Thanks.

--
Message posted via http://www.accessmonster.com

[rdemyan via AccessMonster.com]

It's not that I expect this to happen very often, but it is possible. Do you
normally not do anything about this possible scenario?

It's just that can users ever be sure that they are looking at the absolute
correct state of the data.

Fortunately, for me, my app will be used by small groups with only a few
individuals having the permissions to update data. Further, updates to
tables are typically only once or twice a month.

I just wasn't sure what developers do about this situation if anything.

salad wrote:

How does one handle the situation where two different users are looking at
bound forms that display data from a table.

[quoted text clipped - 15 lines]

Thanks.

I suppose you could put in a timer interval on the form (the value of
the interval in in millisecons so remember 1000 equals 1 second) and
every so often refresh (see Refresh method in help)...maybe Repaint
provides a better description of Refresh in help. Maybe put in a
command button to refresh instead of a timer.

What's happening? Are all of the people sitting at one screen looking
at the same record for extended periods? If I say to Joe Blow, "Hey, go
check out record 1 in the Edit form", and he opened it, he's see what
the values are on my form up to the point of the last save.

Are you sure the person that opened the form first and made changes has
really saved the record?

--
Message posted via http://www.accessmonster.com

[David W. Fenton]

"rdemyan via AccessMonster.com" <u6836@uwe> wrote in
news:5d054b0452ab8@uwe:

It's not that I expect this to happen very often, but it is
possible. Do you normally not do anything about this possible
scenario?

It's just that can users ever be sure that they are looking at the
absolute correct state of the data.

Fortunately, for me, my app will be used by small groups with only
a few individuals having the permissions to update data. Further,
updates to tables are typically only once or twice a month.

I just wasn't sure what developers do about this situation if
anything.

Basically, this is an issue of Optimistic vs. Pessimistic record
locking. With the latter, you prevent a user from making any changes
if a record is already locked. With the former, you let the user
make changes and then sort it out when a save happens. The usual
with Access apps is to do optimistic locking, because in the cases
where both users have made changes in an overlapping timeframe,
Access tells you that and allows you to handle it.

In my experieince, pessimistic locking causes more problems than it
solves, since it guarantees that every lock collision results in a
message to the user, whereas optimistic locking only informs the
user when there really *is* a save collision.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[rdemyan via AccessMonster.com]

Thanks for the response.

My question now seems to be leaning more towards User #2 not knowing that an
update was made, by User #1, to the data that User #2 is viewing. Unless
User#2 takes some action to refresh his/her screen they won't know (absent a
form timer).

I'm trying to find out if developers accept this as the way it is in an event-
driven environment, or do they take active steps to refresh the screen (of
User#2 in this case).

David W. Fenton wrote:

It's not that I expect this to happen very often, but it is
possible. Do you normally not do anything about this possible

[quoted text clipped - 9 lines]

I just wasn't sure what developers do about this situation if
anything.

Basically, this is an issue of Optimistic vs. Pessimistic record
locking. With the latter, you prevent a user from making any changes
if a record is already locked. With the former, you let the user
make changes and then sort it out when a save happens. The usual
with Access apps is to do optimistic locking, because in the cases
where both users have made changes in an overlapping timeframe,
Access tells you that and allows you to handle it.

In my experieince, pessimistic locking causes more problems than it
solves, since it guarantees that every lock collision results in a
message to the user, whereas optimistic locking only informs the
user when there really *is* a save collision.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200603/1

[Bob Quintal]

"rdemyan via AccessMonster.com" <u6836@uwe> wrote in
news:5d05cf97df35a@uwe:

Thanks for the response.

My question now seems to be leaning more towards User #2 not
knowing that an update was made, by User #1, to the data that
User #2 is viewing. Unless User#2 takes some action to
refresh his/her screen they won't know (absent a form timer).

I'm trying to find out if developers accept this as the way it
is in an event- driven environment, or do they take active
steps to refresh the screen (of User#2 in this case).

David W. Fenton wrote:

It's not that I expect this to happen very often, but it is
possible. Do you normally not do anything about this
possible

[quoted text clipped - 9 lines]

I just wasn't sure what developers do about this situation
if anything.

Basically, this is an issue of Optimistic vs. Pessimistic
record locking. With the latter, you prevent a user from
making any changes if a record is already locked. With the
former, you let the user make changes and then sort it out
when a save happens. The usual with Access apps is to do
optimistic locking, because in the cases where both users have
made changes in an overlapping timeframe, Access tells you
that and allows you to handle it.

In my experieince, pessimistic locking causes more problems
than it solves, since it guarantees that every lock collision
results in a message to the user, whereas optimistic locking
only informs the user when there really *is* a save collision.

After 35 years of database design and construction, I've yet to
see an application where the latency issue (user #2 not knowing
that user #1 has changed the data) is a problem. Even in an
Emergency call response center the operator takes a call and
enters the info, then passes on the call to the responders. It
is not 1) enter some data, 2) advise the responders, 3) enter
more data. .
--
Bob Quintal

PA is y I've altered my email address.

[Wayne Gillespie]

On Thu, 09 Mar 2006 23:41:16 GMT, "rdemyan via AccessMonster.com" <u6836@uwe>
wrote:

How does one handle the situation where two different users are looking at
bound forms that display data from a table.

User #1 makes a change to the data, but User #2 is just perusing the data.
User#1 has his bound form updated, but User#2 does not.

In this case User #2 is not seeing the actual current state of the data,
unless he/she does something to cause the data to refresh.

How do developers handle this, if at all?

If it were SQL SERVER as a backend, could one use a trigger on the table to
cause screens to refresh of all users currently viewing data from the table
that was updated.

I haven't given this much thought before, but now I'm wondering how this is
handled.

Thanks.

There is an option under Tools/Options/Advanced called Refresh Interval.
In a multi user environment this setting determines how often a form is
refreshed to show changes made to data by other users.
The default is 60 seconds. If you want your forms to refresh more frequently,
lower the value of this option.
Wayne Gillespie
Gosford NSW Australia

[Tom van Stiphout]

On Fri, 10 Mar 2006 01:34:26 GMT, "rdemyan via AccessMonster.com"
<u6836@uwe> wrote:

I do what David does: use Optimistic locking and have things sort
themselves out at Save time.
You are correct that there can be scenarios a user is not looking at
the absolute latest data. But if you go to the extreme end of this, it
is not possible to always see the latest data. You would have to query
the data source so often, that network traffic would go through the
roof and performance would degrade. So we accept a certain level of
insecurity.

For some applications it makes sense to offer a Refresh buttun: if the
user wants the latest data, that button (or Ctrl+F9) would give her
that.

-Tom.

Thanks for the response.

My question now seems to be leaning more towards User #2 not knowing that an
update was made, by User #1, to the data that User #2 is viewing. Unless
User#2 takes some action to refresh his/her screen they won't know (absent a
form timer).

I'm trying to find out if developers accept this as the way it is in an event-
driven environment, or do they take active steps to refresh the screen (of
User#2 in this case).

David W. Fenton wrote:

It's not that I expect this to happen very often, but it is
possible. Do you normally not do anything about this possible

[quoted text clipped - 9 lines]

I just wasn't sure what developers do about this situation if
anything.

Basically, this is an issue of Optimistic vs. Pessimistic record
locking. With the latter, you prevent a user from making any changes
if a record is already locked. With the former, you let the user
make changes and then sort it out when a save happens. The usual
with Access apps is to do optimistic locking, because in the cases
where both users have made changes in an overlapping timeframe,
Access tells you that and allows you to handle it.

In my experieince, pessimistic locking causes more problems than it
solves, since it guarantees that every lock collision results in a
message to the user, whereas optimistic locking only informs the
user when there really *is* a save collision.

[rdemyan via AccessMonster.com]

Thanks for all the replies.

Wayne Gillespie wrote:

There is an option under Tools/Options/Advanced called Refresh Interval.
In a multi user environment this setting determines how often a form is
refreshed to show changes made to data by other users.
The default is 60 seconds. If you want your forms to refresh more frequently,
lower the value of this option.

Wayne Gillespie
Gosford NSW Australia

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200603/1