Lock Record for Editing on a Linked table
Now, It has been decided to get the necessary tables data in a local tables when application starts, update it locally and then update the original database on server finally.
Everything is done and working fine.
The problem starts here:
Thank you for taking the time to report an issue.
What's wrong... Please write below.
If I'm in a form view does that lock the table?
I don't want the table locked, as I want one user to be able to insert a new record at any time and still allow poweruser to edit current records.
Then in the After_Update event of myName put the following code
I have used this this morning (in a different project to the original question) and it works while I'm still in the record. However when I exit the record and re-enter it the field can be edited again.
Is there a way I can lock this field so that it can never be edited. I don't really want to lock the whole record if I can help it.
If you save the record, you will overwrite the changes the other user made.") even when no other user even has Access open.
This does not happen in other tables in Access, and did not happen in this table before we deleted and re-added the fields in SQL 2005. We can still modify fields in this table using a query - *except* the fields that we deleted and re-added, which now give the record lock message even if we attempt to modify them using a query.
We tried running the Compact and Repair function in Access, and rebooting the system, but the issue persists. How can we fix this?
I have a subform that I have set to open (via button) and view the currently selected record based on a separate subform. This form will be used for editing the record, so I can lock down the previous form to prevent accidental changes to data.
On the subform for editing the data, I have a button to save the record, which I am going to code to run an UPDATE to the table.
Is there an easy way to compare the value on the form fields with the value of its corresponding column in the table, and return either a boolean or integer, then use that value to UPDATE only the fields where the data has changed? I want keep this as streamlined and dynamic as possible,
There are about 20 fields that could possibly be changed, so you can probably see my hesitation to write an individual statement for each one.
I am currently exploring the use of some creative FOR statements in VBA to pass values through variables to the SQL statement, but I figured it wouldn't hurt to ask here whilst I grind away,in case anyone had any ideas off the top of their head that I had not come up with.
I am not a very experienced developer,
In the image below, you have details of the Réf Statut field that is the ID of the status in the table [État des commandes]
Sometimes when opening a form, I retrieve data that was already paid, if a user is not concentrated, then, he might change data in that record, that is the reason why I want to lock the records in the table "Commandes" that are paid.
If we enter data on the form it creates a new line on the table but we cannot edit directly from the table.
So after some time I want the same record that is saved in one table is updated in another table. This table and form is in separate folder just for back up. I mean editing in one table and auto updating in the same table in another folder.
That is one for Back up and another one for editing.
I'm trying to change the name of two or three fields in the Service table, but it causes a pop up when I open the database. I tried to delete the field with same results.
Then I edited the table bound to the subform simply to make one of its text fields longer; that's all!
Now, data from the subform table does not show up in the subform at all.
I can still add a new record via the subform, but I will only be able to see it briefly (while initially entering it). if I go to a different mainform record and then return to the one that should have the new subtable record, again, it doesn't show.
However, looking directly at the table for the subform shows that the new record (and the old ones) are indeed still allproperly there in their table.