After successfully splitting my Access database I have noticed an odd behavior in the primary user form. When I enter a new record in a subform, it moves places after navigating away from and back to an order. Here is an image of the form before navigating away from an order. You can see "TEST ENTRY" is the last record in the subform.
Here is a picture from after navigating away from and back to the order. You can see that "TEST ENTRY" record has moved to the first row, above items entered earlier. Its almost as if the subform is sorting on some criteria I'm unaware of now.
All the data looks good when I view the tables themselves, but I find this a bit odd, as it never happened before splitting the database.
I would appreciate any advice the community has to offer. Much thanks.
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.
Updated***
To quickly summarize what I said before which was lengthy and probably too roundabout confusing...
My issue was I have a main form interface with 2 subforms that does the following:
the First one is always shown for current daily event task(s) based on a label control with current date or any given dates via the prev/next toggle buttons as criteria.
The second one is part of the main subform that will be called based on the selection from the main navigation controls. This subform shows all the event tasks that are created in the database.
Both use saved query select statements with a snapshot and no record lock as recordsource in a continuous form. The table source is linked via split database in the same shared network drive and the table itself contains only 8 fields:
ID (12 chars randomly generated with specific sequence via VBA with no duplicate allowed)
Event Name (Text)
Event Desc (Long Text/Memo)
Occurrence (Text)
Start Date (Date)
Selected Day (Text)
Allow Weekend (Text)
Active (Boolean)
To edit a selected record, it will be called and populated onto a popup unbound model form via VBA. Here everything works fine as for records with fewer chars found in the Event Desc field. However, for records with a large number of chars (so far those that I noticed with issues were the ones with >4000 chars). I can call and display them fine to the detail view form (unbound) but when making edits, by the time it gets to the updating field for Event Desc, it would generate the record locking error by the same user (me) for those with large text size.
After several trials and errors, I noticed it has to do with the displayed continuous subforms that I have presenting. I noticed that the form for them were originally set as dynaset to which I tried to switch over to snapshot and it was a hit and miss (mostly miss). I don't know how much of this setting was an issue to the record updating as I had no problem saving records with smaller character counts.
Finally, I decided to before saving the record, I went and remove the recordsource for both of the continuous forms to empty ("") then save then reassign the query (saved or direct doesn't matter) and it worked without errors after. I personally don't like doing it this way as it makes the continuous forms update look ugly and not smooth (see the #Name?) in the assigned controls due to unrecognized control source since the recordsource is now empty. However, this was the best way that I could think up at the moment.
I even tried using a bounded form for editing the record instead of the unbound form and the same error outcome, but that time it gave a different record locking error# but pretty much for the same reason.
I'm sure this issue is not related to how my VBA code was written nor the queries used in the continuous forms. It's most likely the form settings themselves or just some limitation of Access?
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.
I am working on a purchasing database in MS Access 2010 for a non-profit, and have encountered a problem that I can't seem to solve using other resources.
I have two tables relevant to this discussion, one of purchase orders, and one of line items. Each line item record has a purchase order number (which is actually a text field, as letters are allowed) associated, with 'enforce referential integrity' turned on, one PO to many purchase lines.) In order to edit PO's, I have a form, which I originally created with the wizard, but have modified heavily since then. In the PO editing form is a subform, which displays a datasheet view of the purchase lines table, filtered by the PO that is current in the main form.
Initially, when I created a new record in the subform, it automatically set the linking PO field to the current PO. This way, new purchase line records were assosciated with the current PO. Recently though, the new records are being created with no value in the linking field, and unless I manually select the PO in that column, the record gets filtered out of the view when it is saved.
So the question is, what property controls how new records are initialized in a subform of this type? Is there another problem that is likely to cause this behavior?
Unfortunately I didn't notice this problem right away, so I don't know what changes came in between it working and failing. Furthermore, it seems to be intermittent, working some days and not others (but never changing within one day.) I assume that this just means I'm missing another variable.
Some things that I have tried, based on my research before asking here:
Previously, the 'Link Master Fields' property of the subform was set to the 'ID' field of the parent form. I have now created a text box in the main form that is linked to that field and set it as the master field. To be honest, I don't understand how that would help, but multiple how-to-guides recommended it.
Making the linking field required in the purchase lines table. This prevents the record from disappearing, but doesn't change the initialization.
enforcing referential integrity between the two fields. As I said, it is now enforced, but originally it wasn't. This didn't cause any noticeable change.
Manually saving the record before entering the subform. Similarly saving the subform record before I exit it.
Thanks you kindly for any advice.
I know this post is older, but I just recently ran into this issue and found a solution.
I imagine your database is split. Problems stem when your Access version is greater than the version your database was built in.
Delete the tables from your front end and then relink to them. Reset your forms Master/Child fields and everything should work as normal.
Hope this helps somebody else in the future.
On the subform, make sure both the Link Child Fields and Link Master Fields properties are set to the database fields that the relationship was created on. If the parent form is bound to a record source that includes the key field that the relationship was created on, you shouldn't need to specify a text box or any other control to link on, just the name of the field.