I've been having an issue today where one of my forms is filling all fields with "#DELETED" after I save the record. This wasn't happening three hours ago, and it seems to have started without me changing anything on the form itself. The record is still being saved, and there are no "#DELETED" entries in the table at any point. I am using the following code to open the form:
DoCmd.OpenForm "frmPoster", , , , acFormAdd
This is the code that saves it:
Call DoCmd.RunCommand(acCmdSaveRecord)
I am using Access2010 with SQL Server and VB. As I said, the really confusing part is that seemingly nothing has changed about this form that would be causing this. It worked, and now it doesn't. Any ideas?
Also, if you want any more information regarding the issue, I will be happy to provide.
I've used SQL with Access a lot and had some similar problems, I'd advise unless you have already to make sure you have a timestamp field in the SQL data, and also do a me.requery in VBA after the update so it re-selects the record.
I ran into the same problem yesterday - as soon as I try to save the record, all fields turn to #Deleted. Tried to resolve for hours - no luck.
I use Access 10 / 2016 and MySQL ODBC connector 5.3.
I narrowed it down to one specific field with a 13 digit number.
The datatype for the field was varchar. When I enter any value that does not match the required format (as checked by VBA), and then delete or edit it and move to the next field, the form refuses to create the UserID upon save and gives #Deleted.
If I skip this field during data entry, then the form creates the UserID (Primary Key) and saves. Also, if I enter a value that matches the field criteria first time round, the form generates the Primary key and saves.
As suggested somewhere I changed the datatype to numeric 14,0 for this field.
This did not help.
I tried to requery the form after saving as suggested but since the record is deleted, it simply displays blank fields.
So here is my hack:
1. On the "On Enter" event of the first field in the form, run code to set temporary values in each of the required fields, for example:
First I created an unbound hidden field with default value of "No". Then:
If Me.NewRecord=True and Me.FormPreppedYN="No" then
Me.txtFirstName="Hello"
Me.txtLastName="There"
Me.IDNr=123
Me.Ref="ABC"
Me.Dirty=False
Me.txtFirstName=""
Me.txtLastName=""
Me.IDNr=Null
Me.Ref=""
Me.txtFirstName.SetFocus
Me.FormPreppedYN="Yes"
End If
This forces the form to create a Primary key. This happens very quick and the user doesn't notice it. They just enter the data.
This worked reliably every time. I still don't know what causes the error, but this fixes it.
Related
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.
I have a relatively simple Access Form that I use to catalog items in a collection I have. It all works beautifully...most of the time. The one thing that I cannot seem to figure out this:
I have one control bound to a Multi-Value field in a table (yes, I know, I know...don't use Multi-Value fields). When editing this field via the Access Form control, I am able to add values and delete values, but if I try to delete ALL values in the field, I receive an error message advising that the record cannot be saved, and Access is not able to move on to the next control.
I've searched the internet for similar issues and found nothing. Anyone have any ideas? Thanks in advance.
In the BeforeUpdate event on my field, I have a dcount set up to disallow duplicates in the field SurveyID. This works great, except in the event that, in a past record, the user starts editing their SurveyID by accident and tries to cancel (accidentally selects the SurveyID field, starts typing, then erases it and enters the SurveyID). It reads that SurveyID as a duplicate (even though it's not really) and won't allow them to keep the ID. I've already done a half workaround by having the SurveyID reset after this, so if they're in the above scenario they can at least retain their ID. What I really want to know if there's a way with my code to prevent this from happening. The SurveyId is NOT the primary key, as there are two different ID codes they could have used. Maybe an extra piece of logic saying that if the primary key in that record in the form matches with the primary key of the "duplicate" (aka itself) then it doesn't get processed at a duplicate?
Here is my current code
Private Sub SurveyID_BeforeUpdate(Cancel As Integer)
'checks for duplicates'
If DCount("SurveyID", "test", "SurveyID=" & Nz(Me.SurveyID, 0)) > 0 Then
Beep
MsgBox "The Survey ID number you have entered is a duplicate. Please double check that the number you entered is correct. If it is correct, please X."
Me.SurveyID.Undo
Cancel = True
End If
End Sub
Have you tried setting SurveyID to be indexed as Yes (No Duplicates)? As long as Required is also set to No it should not allow you to enter a duplicate value but you can also leave it blank if you wish.
You should still be able to trap the error in the form's On Error event so you can display a friendly message.
This is exactly why having a bound form is a bad idea. Never, ever bind a form to a table. Undoing an entry is wonky at best, and the way a bound form works is that as soon as you change fields, the record is written to the table. Yes, there is an Undo command but it's not reliable.
Unbind the table from the form, and write code that either updates a record (if it already exists) or writes a new record when you press a "Submit" button. It's a lot more coding and requires a better understanding of Access, but it's the proper way to do this.
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.
This is my first database I am building, and am no Access expert, but I do think that I understand the basics.
I have deleted an old field from the back end of a split database, and edited the record sources of the forms that use the table as the record source. I deleted several fields, but one (a number field) is giving me trouble. Whether I open the underlying table or the forms that use the table as a recordsource, an "Enter Paramater Value" Dialogue box appears asking for the value on the form. I have looked at an older version of the database, and the field is not a primary key. I am quite stumped on this one. I have confirmed that the field is deleted from the recordsources and the table, so I'm not sure why it is still behaving like this.
Thanks.
Check Order by and Filter properties of the forms and queries which show such error.