I have a table in PhpMyAdmin and agents go in and edit a field in each row with something like a "yes" or "no".
Since all agents are working on the same table in PhpMyAdmin at the same time is there any way to prevent an agent from editing the field in a specific row if another agent is editing that field in that row?
I want to prevent rework from happening.
No, I cannot have each agent have their own table - in case someone asks that.
I don't believe so. You might need a tiny little UI program that allows agents to open a row (which would lock it by updating a Boolean or something) and prevent another agent from opening the row. Saving/Canceling would unlock it.
Related
I have a row in a table which I use for auto-numbering other fields in the same table, if this row is edited it can mess up the sequence. How can I stop users who are making use of this database from editing this one particular row?
You can't. If a user or process creates a new record but regrets the action, the number is lost.
The Autonumber is designed to uniquely identify the individual record, nothing else. If you need a sequence number or similar for any other purpose, roll you own function. There are plenty of examples out there for the browsing.
I want to preface this by saying I don't have any real programming background, I'm just trying to update an existing database at work.
We have an access database and I want to add an additional Y/N checkbox to an existing form. The form updates a SQL table. Currently the record source is a SQL statement.
I can go to the SQL table, add a new field and make it Yes/No data type. There are other Yes/No fields in the table and the default settings for the new field are identical to the others. I next go and update the linked table through External Data in the ribbon. I can go into the table in Access and see the new field - so far, so good.
Next, go to the form design view and form properties, go to the record source, update the SQL statement to include the new field. (I've also tried this thru query builder, same result.) From here, I start to get the error.
If I go back to form view and change any data in the form and hit the next record button or save button, I get the Write Conflict error. "This record has been changed by another user since you started editing it..." The 'Save Record' button is greyed out. I am the only person accessing the database or SQL server.
I've tried to finish building the new button and linking it to the new field in control source (that went fine), but it didn't make any difference. If I go in to edit the record source and remove the new field, everything works again (but of course, the new field isn't in the control source list, so isn't linked to the check box).
Any ideas? Thanks.
A strong contender for the reason for your problem is the form itself.
Most likely the form is setup with a specific query as the Record Source. Its not to say that that is inherently incorrect, but it makes adding new columns to the source significantly more difficult.
The problem would likely be solved if you just changed the Record Source to reference the table itself, rather than a query, if that is in fact how it is referenced.
If Ms Access tries to pull data from a table using a query through a form it will inherently Pessimistically Lock the table in question, making it unable to be modified. However, you can usually still modify the table through the query itself, but you would need to add the column changes into that query first.
I'm not quite sure if I am making sense here, but something like this (for a table called "Table1"):
In theory, if the form is the problem... then if you closed it and tried to make modifications to the table, then the changes should work when the form is closed.
Someone else fixed it for me, but from what I understand, it was a communication issue between SQL and Access. Something with the setting of the null value in SQL not being set the way that Access could understand.
We had the issue narrowed down. When the new field was added to the table, you couldn't change any info directly in the table, but you could with the form.
If you added the new field to the form's record source, you couldn't edit any info at all.
Thanks for everyone's input.
Hopefully the image above makes it thru. So the way this works is that a user uses a form to enter the values on the Vuln_Remediation_Planning table. After all vulnerabilities associated with a patchID and existing OS have been entered, he moves to the next form where he is suppose to mitigate the risk associated with the vulnerabilities, and you can have multiple mitigating measures which is why the table is separate.
My question:
Right now when using the compensation form, the user has to select each patchID, OS, and vulnerability ID for each mitigating measure they select... this is cumbersome and error prone. Recall the first form only operates on the planning table, the second form operates on the compensation table.. but they are related so I feel the user would want to use a single drop down to select the top the primary keys, already assign in the previous table.
I was going to ask how to handle this, but I may have solved my own problem... 3 column combo box right, with the row source coming from the Remediation planning.... lol what do you think, any other ideas?
I figured it out. On the compensation table I just created a continuous form, and moved the OS and patchID fields to the header. When opening the form normally, it looks funny because the header values change when records are selected (as would be expected if they were all on the same row). Then from the remediation planning form, I have a button to open the compensating measures form that filters it so only the patchID/OS of the parent for is shown. Additionally, in the open event of the compensating measures form, I set the default values of PATCHID/OS using open args (in case no records are there yet or the user adds new records... otherwise it opens blank when there are no records.
So I have two issues with my database, which I think are linked together.
Firstly if tblDeliveries is empty and frmMainView is opened it comes up with "You must enter a value in the 'tblDeliveries.deliverySlot' field" but the form shouldn't be trying to create a record and I can't see any reason why it would. Opening frmDailyView (which is a subform of frmMainView) doesn't show this behaviour but it is the one with the continuous form on...
Secondly if tblDeliveries has one (or more) rows the first row of the table will jump about... For example in frmMainView if the date of the first record is set to 23/01/2015 and you navigate to the 24/01/2015 and click anywhere on the subform and then press F5 to refresh the record will have jumped to that date, the date even changes in tblDeliveries.
I have no idea why it's doing it, I even removed all of the VBA code for the form to stop it, but it happens anyway.
If anyone has come across anything like this before, please let me know how you fixed it, or any suggestions would be very welcome. Thanks!
EDIT: If you download the database, add your computer login name to tblUsers. Also the date is UK formatted, so might need tweaking to work with US dates.
The offending database (1.5MB)
Taking a look at your database, several issues are occurring.
You first issue can be resolved by going into the Design View of the table tblDeliveries, select the deliverySlot field and change Required (in bottom panel) from Yes to No.
Your second issue is multi-faceted with many issues but a critical problem is that the parent-child link field, deliveryDate, between the main form and subform is missing in the recordsource of the sub form and the field's table origin is not in the query's join statements. For me, I can't even update anything in subform (all boxes are grayed out).
Essentially, you are trying to normalize Delivery Dates and Delivery Times (one-to-many) but the left join query (qryDeliveryIncBlanks) setup is not aligned to this effect. You user login also does not integrate smoothly into frmMainView. My ultimate advice is revamp your database design relational model then use forms as the visual representation of those related tables.
I am not re-iterating the points of #Parfait.
Access Forms have a property DataEntry. If it is set to Yes (or True in VBA), then the form will open itself pointing to a new empty data record. Set this property to No (False in VBA).
If you want to give the user the possibility to manually enter a new record, set the property AllowAdditions to Yes and to No otherwise. Yes displays an empty record marked with a star * and the end of the data sheet or continuous form.
I've resolved the issue, thanks to some of the comments I realised I could just give the deliverySlot field a default value with a number outside of the range it would look for, I set it to 99, but it only looks for 1-20. The date still jumps around but since it's not in the range of the query it's hidden. It's resolved both issues.
In a Related Tables, you need to enter a FK to link to the parent table.
You either key in the FG from memory !!!!!! or use help.
The standard procedure is to design the field as combo box AND use SQL to select the field that will help to input the ID of the parent table. So, if you want to input foreign key 3 , the combo box will display what 3 is then when you selected Access will insert 3 for you.
My question is since I can later on, edit the table and change the the value to another value, and mess the whole thing up!!! HOW can I lock my first choice so it will stay unedited ?
My second question is: Is this the only way to input the FK if you do not remember the exact ID number or there are thousands of records in the parent table.?
Re. #1
In Access 2010 you could use a trigger to check whether the value has been used in another table as a FK and not allow the change. In previous versions all you could do, would be to hide the navigation pane or make the table hidden.
Re. #2
You could use a listbox (basically the same idea as a combobox).
You could include the lookup table in the underlying query, but then there is more danger of the values getting changed, which is exactly what you were worried about in the first question.
Stick with the combobox.
You can create different versions of a form. One might have Allow Edits, No, another might be Data Entry, Yes, meaning that it can only be used to create new records.
However, suppose someone is creating a new record and they select the wrong FK by mistake. How can they correct this? You could use VBA to produce a confirmation dialog in the first instance, and perhaps an Undo button where VBA would deliberately perform the Undo. Access 2010 also has Data Macros (equivalent to triggers) that you might use to store the old and new values, and other information, when a user changes a FK value.
Access does not implement user-level security, so the user can still open and change data in the raw-data tables. You should, however, have enforced referential integrity on the table-join, so that a user cannot enter a FK that doesn't already exist as a PK in the related table.
In summary, you could add additional columns to the combobox to help the user select the correct item, and you might consider an additional confirmation dialog (a MsgBox) before a record is saved into the data-table. But you cannot prevent people from making mistakes. (Enforcing Referential Integrity will prevent nonsense data from being entered.)
Second question:
A combobox (or possibly a listbox) is the easiest way for users to enter a FK value, without relying on memory. An alternative would be to use a button (or other control and event) that opens a secondary form. This form might have some filtering features to help the user find the correct FK value. When this form is closed you would then need to write some code to update the relevant control on the main form.