I have a 2010 sharepoint list. It's linked to Microsoft Access as a linked table. I'm trying to make some updates in Access. The SP list has no lookup columns, all of the People-type fields are People Only (not People and Groups), there is no referential integrity set because there are no lookup columns, and absolutely none of the columns are required. Also, there is no Validation set on any column in the List Settings.
I get the error: "You cannot update this field because the value you're trying to apply is not valid or would break a data integrity rule. Please correct and try again"
The thing that's frustrating is, if I ADD records (using Access), I can do that, and then I can EDIT those records. When I first add them, I don't include any People information (because it seems I cannot do that from Access) - I leave those columns blank.
If I THEN go, at that point, to my newly created records, in sharepoint online, and add some People information, and then go back to Access, suddenly I cannot do ANY update in ANY column - I get that error message.
Anyone know what this might be or what I am doing wrong? I'm not even trying to update a People field in access at this point - I'm only trying to update fields I was easily able to update in Access a few minutes ago--just BEFORE I populated those People columns with data in SP online.
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.
Hello helpful internet strangers. I have created a fairly simple database for a client that has one main entry form and a search form that uses unbound text boxes for searching around 15 fields.
Details are below, but here is my problem: When I add new records and use the search form all the fields work as expected and return the correct results in the datasheet. When I sent the database to the client and they add new records, they are not returned in the search. I had them save the database with their records and send it back to me, and I confirmed that when I search for the records they added (I can see the records in the table) they are not returned in the search. If I add new records to the copy they sent me back, my records do appear in the search.
I created the database in Access 2013 on a Windows 8 machine. The client is using Access 2010 on Windows Vista.
The field types are text, dropdown and date. The dropdowns are all based on lookup queries so they store the id number in the main info table and pull the name value from the query. All of the fields in the search query are written to allow nulls, including the date range searches. And again, all fields test out correctly on my machine when I enter the records.
I went on site and compared settings and nothing jumped out at me except the different versions. I also watched the client enter new records and she didn't do anything 'wrong' or unusual. When I try to do a save as 2007-2010 it says I am using features that won't allow for that, but for the life of me I can't think of anything like that since this is really a very straightforward design.
I'm going to do a package as executable, but am highly doubtful that will help. Any insights?
Thanks in advance.
A few things. Most important - always, always develop in the earliest version of Access that the system will be used with. So, you need to rebuild, using Access 2010, period. Try creating a new blank database (in 2010) and importing the objects one (or a few) at a time. Make sure the system is split. One file for the FE (forms, queries, reports, code, etc.) and one for the BE (tables only). Make sure that the Filter On Load property of all forms is set to No. If the recordsource for the form contains a where clause, make sure that the newly entered records meet the criteria for the where clause.
I haven't done much in Access for years, but I have picked up a bit of support work to help out.
Database is an Access 2003 one, running on 2010 in compatibility mode (Behaviour was the same on 2003 though) with the data in a SQL Server 2005 backend.
We have a single form (i.e not master/subform) that is based upon a query, joining 2 tables - it's a simple organisation to address. It is theoretically many to one, but in practise one to one. I wasn't even sure if/how this would work, but it does in general.
If you create a new record (The form has a button, but it's the same if you use the built in new record button) it happily generates a new address ID from the autonumber on the tblAddress table, and populates the org_addr_code column in the Organisation table.
However if you then try and create a second new record, it throws an error
The Microsoft Access database engine cannot find a record in the table tblAddress with key matching field(s) 'ORG_ADDR_CODE'
If I hack records directly into the datasheet view of the underlying query, then it lets me add as many records as I like.
If I exit the form after inserting the first record, and go back in, I can add another record just fine. It's only if you try and do it more than once in the same form 'session'. I have tried every variation on refresh/requery I can think of, but no joy.
Anyone got any ideas? I'd rather not have to rewrite the whole form - if it came to that they will just have to stick to adding one record at a time.
Carl
I have an ancient Access application that I've recently moved the data to a SQL backend using the SQL Server Migration Assistant, and almost everything is working except for one issue.
In the application, we have a form with another form inside of it. The outside form finds specific "issues" entered into the system, and then looks for a history record(the inside form) that is associated with this issue. If a history record is present, it works perfectly, as the record shows up in the embedded form just fine. However, if there is no history record yet present in the database, the entire details sections of the embedded form blank out entirely. The properties are all set exactly the same as when it was a pure Access Database, but now that I've switched it to pull from SQL using Linked Tables, the form is now blank when I don't have a record to pull from.
EDIT: I learned that there are two conditions that when both met will cause a form's details pane to go blank: (1) there are no existing records to be displayed, and (2) it is not possible to add a new record.
This means that the second condition is where my issue lies. I tried scrolling to the bottom of each of the linked tables in Access, and for the History records table, I was not able to add any new rows, but for the Issues table, I was. Something is keeping me from being able to edit this one table for some reason.
I think the behavior you described may happen when the record source of the subform (your "inner form") is read-only. When matching rows exist, they are displayed. But, when no matching rows exist, you can't add a row so the subform's bound data controls are disabled.
Open the subform in Design View. Select the form and open its property sheet (Alt+Enter). Find the Record Source property on the Data tab of the property sheet. If the property value is a SELECT statement, copy it and past into SQL View of a new Access query then switch the query to Datasheet View. If the property is the name of a table or saved query, open that object directly in Datasheet View.
Once you have the form's record source opened in Datasheet View, are you able to add a row? If not, make sure the SQL Server user has INSERT permission for the data source. However, even with INSERT privilege, Access may have linked the data source as read-only if it was unable to identify a field or combination of fields which uniquely identify each row. If that is the case, you may need to re-link the table and tell Access which field(s) to use as the primary key.
I'm using MS Access 2007 as a front end and have all linked tables in SQLServer 2008 R2 backend.
In a form in Access I am trying to execute the FIND button either in the ribbon or by creating a button on the form with the expressed purpose of looking for records with a specific value in a particular field.
When I complete the entry in the FIND window, I click on Find Next. In some cases, the record(s) is found immediately. In others, it can go for hours only to report that it can't find anything (when I know it should).
The table I am looking in has approximately 99,000 records in it. It doesn't seem to matter whether or not the field is indexed.
Is there something I'm doing wrong, or is Access unable to handle this? Also, is creating a stored procedure with handling multiple search requests and passing the info to Access the answer?
The find methods are known to be slow with ODBC data sources. Here is what the Access 2007 Recordset.FindFirst Method help topic says:
When working with Microsoft Access database engine-connected ODBC databases and large dynaset-type Recordset objects, you might discover that using the Find methods or using the Sort or Filter property is slow. To improve performance, use SQL queries with customized ORDER BY or WHERE clauses, parameter queries, or QueryDef objects that retrieve specific indexed records.
Futhermore, binding an Access form to a record source of 99K records is a performance challenge. Use a query as the form's record source, and design the query to return only one or a few rows.
Give the user an option to choose a different set of rows, and modify the form's record source property to reflect the user's choice.
This depends on the type of search you need and on the data type of the column (field) to be searched. For example, if I have a text data type in an indexed column and I search using Start of field or Whole field, it will be quite fast, however, if I search for Any part of field, it may well fall over. In other words, if Access can use an index for the search, it will work, even on quite a large table, otherwise, you may be best with a stored procedure, though I doubt that will be fast without an index, either.