"DoCmd.RunCommand acCmdRefresh" documentation.

Hello Finch,

To the best of my knowledge there is no documentation on the Runcommand options.

They do whatever the corresponding menu option would do.

In this case the data is refreshed for whatever object has focus at the time the command runs.

Pete

This example accepts the name of an open table and refreshes the data.

Sub TableRefresh(strTable As String)
    DoCmd.SelectObject acTable, strTable, False
    DoCmd.RunCommand acCmdRefresh
End Sub

In the example you've provided, what happens if user #2 hits the database with a Command during the time in-between the two DoCmds?  Is the object from  User#2 the object which has focus ???? btw there are multiple users sharing a common MDB database that is located on a server.

Sub TableRefresh(strTable As String)
    DoCmd.SelectObject acTable, strTable, False

?? What happens if User#2 DOES SOMETHING HERE???

    DoCmd.RunCommand acCmdRefresh
End Sub

The program is executing on the user's local pc.
User 2 cannot interfere with what is happening on user 1's screen.

If both users are changing the same data then you might get locking issues.

What exactly is the problem you are trying to diagnose?

Pete

There seems to be some level of interaction between user-1 and user-2.  Sometimes it is Lock issues but I've changed the record in question to be 2048 Bytes so there should not be record-locking issues, also I've added "retires" around all .Edit and .Update commands in this module.  What I've done as a test is to put both user-1 and user-2 into loops where both are hitting the database (MDB) and both are using the acCmdRefresh.... the acCmdRefresh on user-2 seems to cause lock-errors or other object-errors on user-1.

Any suggestions on hpw to protect or isolate the various users?

I can't tell from previous post whether you have split the database into frontend/backend operation, with each user having their own copy of the frontend.
This is always the essential first step in a multi-user set-up.

Pete

Yes, it is split.  Backend is an MDB database on a server, each user has a copy of the frontend which is an MDB program.

'There seems to be some level of interaction between user-1 and user-2.  Sometimes it is Lock issues but I've changed the record in question to be 2048 Bytes so there should not be record-locking issues'

2048 is the page size for A97.
It's 4096 for A2000+.

When you did this did you fill the fields with text?  Access only uses the space it needs to hold actual data, not the full declared field size.  

But if you are not referring to locking issues what do you mean by 'some level of interaction'?

(These sort of problems drive you mad, don't they!)

Pete

That does shine some light on why packing the record size did not resolve my issue.  I did not know the record size is 4096 and I did not realize that Text fields would not make the record a fixed size..... Thanks

Now the issue is that making the record size 4096 would result in way too much waste.

The issue is that the operators are very fast typists and do not see the little black circle in the datagrid that warns them of a lock... So if I can come up with a way to save the keystrokes or maybe force them to pause from entering data for a short time while the lock is resolved (or even better if I can know when the lock is active) I can make them happy and be a hero for at least an hour.

Any suggestions? Is there a way for me to programmatically know when the "Black-Circle of Lock" is present?