I have removed the lookup information from a back-end Access table.
When I open the front-end mdb and try to view the raw data in the table, I am presented with an 'Enter Parameter Values' dialog box, and Access is indicating that it wants a value for 'Lookup_[ForeignKeyColumn].Desc'.
I can view the design of the table in the front end, and on the lookup tab, all the fields are set to 'Text Box', so it doesn't look like any references are floating around.
Queries are still fine - I can access the data - just looking at the table on its own is the difficulty.
Has anyone seen this before and knows what to do?
The solution: Refresh Linked Tables
From the front end, I had to go into Tools -> Database Utilities -> Linked Table Manager
and nominate to update all files.
Access has a lot of "ghost" issues. I've been working with it for 20 years, and I can't tell you how many times I've had to rebuild databases because mystery queries were running in the background, or forms continued to require data entry, even though the controls had been deleted.
Try creating a new, fresh database with nothing in it. Then, import all of the forms, queries, modules and macros into it. See if that fixes the issue.
I faced the same issue, however for me refreshing the linked tables did not work, neither did relinking the tables after first breaking the links.
In my case the field "Order By" in the property sheet of the front end table was filled. Clearing this resolved the issue.
Related
Why would my form/subform mislink records using SharePoint List back end?
I have years of experience with MS Access, but this is my first time with SharePoint List as a back end.
I developed a small database for a small non-profit. Started off with Access 365 front end and back end, located on one user's computer. This ran fine and correctly for a few months, and last month we migrated the back end to SharePoint Lists so that two other users can use the database. They each have the front end on their desktop.
There's a bound form, Events, linked to tblEvents. Subform, subVolTime, on this form is linked to tblVolTime, to show the volunteers and how much time they spent at the event. In the subform property, Link Master Fields is set to tblEvents.ID; Link Child Fields is set to tblVolTime.EventID. There's no extra VBA code.
We migrated to SharePoint Lists using the wizards, and did nothing else. Shortly afterwards, my user noticed that the wrong people were showing up under events. He can tell just by looking at the names.
I created an audit query, and I can see that in some cases the dateAdded (date the record was created) in tblVolTime is BEFORE the dateAdded of the event in tblEvent. This can't be right, because you must have a record in tblEvent before an associated record in tblVolTime.
For example, there's an event ID 261, created on 4 Nov 2021. The records for the volunteers linked with this eventID were created 7 Oct 2021. Something went wonky.
Any suggestions are welcome. My ideas include: unbind the form; hide the subform until the event record is saved; create the event record before the user actually adds any data to it.
Well, hard to tell. However, unlike moving Access data say to SQL server?
Moving data up to SharePoint is VERY MUCH a different process. Why?
Well, for one, when moving data to SharePoint, the auto number PK's you have (and you MUST HAVE FOR ALL TABLES) are often re-numbered.
Now, due to this re-numbering of auto numbers?
Well, that means before you migrate the data, you BETTER really, but really and beyond really sure that a relationship was setup between such tables.
In the case of Access, while in most cases we do have a correctly setup relatonship, to be honest, you REALLY never had to do that. In other words, if I setup a master link and child link for a sub form? Well, access would just generate the PK autonumbers for the main table, generate the pk autonumbers for the child table. And THEN during a data insert would correctly insert/set the "FK" values in that child table to the parent table. As long as the link master/child settings were correctly setup (but no actual relationship was setup), then the application would happy work.
If one was to migrate the data to say SQL server? Well, since the PK autonumbers are NOT touched during this up-load process - then all relationships and their data would ALSO make a valid trip up to SQL server.
However, in the case of SharePoint? Autonumbers for ALL tables are and will and in most cases are re-generated!!!!
But, this tends to not be a problem if you up-sized the data using Access. It has built in SharePoint support, and say if a parent reocrd goes up from Access to sharepoint and the PK id is changed? No probem, since if you REALLY did setup,and you REALLY did have a relatonship setup, then the migration process is smart enough to go find the child reocrds, and update the FK values. But of course the migration process can ONLY do this magic trick if you KNOWS about the realationship.
Another simple example?
Say we have a simple form, and we have a SMIPLE combo box to pick say favor color.
tbColors
ID (Auto number PK).
Color (text color).
So, so now we have a simple form, and we dropped in a combo box. When we choose a simple color like "red" or "blue" from the combo, we of course are saving the "pk" id from the above table.
Now for a LOT of simple tables like above, never used, or bothered with setting up a realtonship. (no need - just a few choices from a combo box).
And if you were up-size data to sql server? Again, this would work fine - no problem at all.
However, if you up-size to SharePoint? You REALLY but REALLY better have setup a relationship even for this simple silly little combo box. Again, the reason is simple. When that simple table of pick list values goes up to SharePoint, the autonumber PK id's will change. And thus for any other table that used that simple pick list? You have and MUST have setup in your relationships window that this was in fact the relationships - and again, the reason is re-numbering of autonumbers.
So for ANY relationships that used PK and FK values? They MUST in ALL cases when using SharePoint MUST have been defined in the access data tables (relationships window) BEFORE you transfer that data. And again, the reason is simple - during a up-load process to SharePoint, autonumbers WILL CHANGE!!! And since they change, then any other dependent table that uses those PK values (as a FK) MUST have been part of a defined relationship. If they are not defined before migration to SharePoint, then a change in a PK value will NOT tell SharePoint to go and find and correctly update all of the "child" records or so called FK values.
So, the first question to ask is did this break in related numbers occur a long time ago (at migration time), or did this break occur due to some bad code, or the wrong values having been selected?
So, migration of related data to SharePoint is a "delicate" operation, and the main reason of course is that the related tables MUCH have been setup as enforced relationships BEFORE you migrate. If such relationships were not strict defined, then during the migration process then the relation of data based on those PK/FK values will break at that migration time.
Now, it could be a simple issue that this sub form in question does not have the correct link master/child settings - that's the first thing to check.
I am using Office 365 with MS-Access that is tied to a SharePoint list. I have some VBA code that runs with the user clicks on a command button. Part of the code appends data to a table. Unfortunately, one user kept trying to use the command button not realizing that the connection to SharePoint, (for some reason), was lost. Everytime she clicked on the command button it appended the same data. I need some vba code that checks if SharePoint is online for MS-Access. If it is, it runs the query. If it isn't the coded exits along with a message. It's finding out if SharePoint is online for MS-Access that I need help on.
Well, if you are in off-line mode, and you have the cache turned on, then that user should be able to freely add records. The PK will start at -1, then -2 and so on.
You could check for a internet connection, but if they are flipped into off line mode, then Access will often remain in off line mode.
So, you could have a dummy table, and add a record - if the PK is < 0 then you are off line (and delete that dummy record). I am not aware there is some command that will tell you that you are in fact on-line. I suppose you could also "ping" the server with a shell() command, but as I stated, you can actually be off line with a valid connection, so to be really sure the negative PK trick would tell you for sure if Access "thinks" and is "behaving" as if it is in off line mode.
It is not clear why the button fails, but if you have the check box "use SharePoint 2010 or later cache) selected, then users should be free to edit, view and add records. when you re-connect, then access will sync all the changes and updates (bi-directional sync).
Albert. Thank you, your suggestion was helpful. I did some testing by disconnecting my computer from the Internet and then running the code attached to the command button. Like you said, in the SharePoint table, (not a temporary table), all of the records imported have a PK <0, i.e.-1, -2, -3, etc. I wrote a simple DCount query looking for PK's less than zero. What was interesting is that the query could not count any PK less than zero, only PK's >0. My workabout in the criteria was to place, Like ("-*") and that worked. Wierd that the PK is an autonumber field, a number, but less than zero didn't work. With the DCount criteria I created a MsgBox that explained what was going on and how to get SharePoint back on line if there Internet connection was still up. AND, don't import the same spreadsheet again, (which was part of the code. So, thank you.
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.
Hello I have a pretty intricate Access database. I just jumped on this project and have never used Access. I have a form that is generating a value entry popup when I try to run it and it shouldn't be. The problem is the form is trying to access a column of a table which has been changed recently. I just have no idea where to find the query or what exactly is trying to access that column. Any help greatly appreciated. I am using Access 2016 also.
Sounds to me like the problem inst actually your form but the query your form is based upon.
This may be a separate query or a query built in your forms record source.
Go to your form in design view. Open up the property sheet. (Under design tab) make sure the dropdown box has Form Selected and look at the Record Source.
The record source may state a query name, In which case you should remove the field/replace the field with another in that query.
Or if it says something along the lines of "Select ......" then just alter that query to not have the field you have removed/renamed and the problem should go away.
However it is worth noting that if you have sub forms it could be the record source of one of those.
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.