I am working on a split database in MS-Access 2010. The back end has relationships between many of the tables. My problem is the front end does not seem to recognise the relationships when I am designing forms, and the relationships do not show up in relationship view. For example, the field 'Service' in tbl_BAYGCharges is a lookup field pointing to the ID of tbl_BAYGServices, so tbl_BAYGServices.ID is related to tbl_BAYGCharges.Service in the back end. When I try to create a form for tbl_BAYGCharges that includes fields from tbl_BAYGServices, the tables do not show as related under 'Add Existing Fields' and a 'Specify Relationship' pop up appears.
I followed the instructions given on the MS website when splitting the tables and have tried re-linking all the tables which had no effect.
I'm relatively new to Access but I am assuming there is a problem here - I want to avoid having to manually create relationships every time I am creating a form and am worried about the future repercussions if the relationships in the back end aren't being recognised.
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 currently have a Multi-Value field based on a list of e-mail address, in MS Access 2016. Both the destination table, and the table where the list is pulled, are linked tables. The ComboBox doesn't work for either Queries or Forms when the destination table is a Linked Table. It works for regular Table.
I wish to save multiple e-mail address in this field, without having to use a secondary table (this would be a better design, but would make building forms a complete nightmare, both for me and the users). The inner data storage is a CSV-like format with a ";" delimiter, automatically handled my Access.
To answer obvious questions :
I will not use a separate table as "Good Design" suggests, to not kill UX and database simplicity.
There is no VBA involved at all anywhere in that selection form.
Question : What am I missing, and what can I do to make this work in an MS Access Form with a linked table?
Here it what the selection tool from Access Form looks like :
The solution ended up being :
Unlink the table from the front-end
Re-link it
It seems like any complex field (Multi-Value, Calculated, Attachment) requires a re-linking of the table.
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.
I'm designing an Access 2010 web database, and I'm trying to create a subform that will display data based on joined tables. It displays alright, but I can't modify the data. The two tables are called Consortiums and PrincipleInvestigators. There's a many-to-many link between them, so I have a ConsortiumsPrincipleInvestigators join table.
I have a "consortium" form which displays the data related to a specific consortium, and has a subform within that form that displays the principle investigators part that consortium. I was able to successfully all the PIs, but when I try to add a principle investigator within that subform, it gives me an error: "Cannot add record(s); join key of table 'PrincipleInvestigatorsConsortiums' not in recordset. What gives? I imagine it's because I need to update both the PrincipleInvestigators table and the join table. (Also, MS, why can't I just use standard relational database stuff instead of this silly lookup field business?) Here's some screenshots of my table layout and my join table:
http://i.imgur.com/j4RJQ.png
Bleh. I feel noobish although I've done a decent amount of database projects, but the lookup fields and query builder is throwing me off. Does anyone know of any good tutorials on how to design queries?
There is really nothing that changes in terms of building a relationship between two tables. The fact that you use a GUI, a SQL DLL command, or now some relationship wizard changes nothing.
I mean who cares what the process is much to setup a relationship between two tables?
I mean, in client based you could type in something like this:
ALTER TABLE Cars
ADD CONSTRAINT MyColorIDRelationship
FOREIGN KEY (ColorID) REFERENCES Colors (ColorID)
So, now you use some wizard that is a few mouse clicks and this is some big deal? Really, who cares! No big woopy here, all we care is that you execute some command, or some wizard, or something here and you at the end of your day the result is your beloved relation between the two tables.
Check out the following video of mine where I "hook up" some existing related data into a web database. And I ALSO share how you can printout the related tables using the Access relationship window for a web database:
http://www.youtube.com/playlist?list=PL27E956A1537FE1C5&feature=plcp
So, at the end of the day, no need to get twisted up in some details of having to use some DDL sql command, some GUI relationships window, or some wizard. All you are doing as the above video shows is hooking up some tables and setting up a relation – nothing more, nothing less to worry about.
As for how to add child records that are to be related to a parent record? Well, in the past for the last 18 years, quite much every bird, dog, and beetle using Access would simply do this:
a) Create a main form based on the ONE main parent record table. There is NO NEED to build a query here, and in fact NO need to build a query that is a join of the two tables – this was never required and is not required. All you do is build a form based on the one simple table. We are done this part "a".
b) Create a form based on the ONE child table. There is NO NEED TO build a query here, and in fact NO need to build a query that is a join of the two tables – this was never required and is not required. All you do is build a form based on the one simple table.
c) open up first form (the form based on parent record table) and then in layout mode, now drag + drop in the child form from the nav pane.
The above a,b,c steps is how virtually EVERY parent to child setup in Access I seen done, and this long time forever setup CONTINUES to work 100% in web based applications.
In both cases (web or non web), the setup remains the same, the setup does not involve building quires, and the setup does not require ANY coding on your part.
As long as the link/master child settings are correct in the sub form control, then you are free to add child records to the child form and Access will do the rest of the dirty work of setting up and maintain the relation for you by setting the FK column in that child form for you.
So, how the basic setup works here has not changed in 18 years of using Access, and as such this does not change when building a web form here.
You don't need a query based on more than one table, and in fact JUST like in the past, the two forms will as a general rule will have their data source based only on the one table.
So in most cases there was never a need to even use a query for that one table that the form is going to be based on. This long time basic approach and setup has not change for web forms either.
In your case I would assume the main form is Consortium. You child form could be a continues form based on Principleinvegiartors. And in place of having to manually enter some PrincipleInvetigaor ID, you use a combo box based on table PrincipleInvetgioars. However, again in all cases, we are simply building forms that are based on a single base table.
For this situation, you should choose one of your tables for the main form and the junction table for the subform.
For example:
Main Table
Consortiums
Subform
ConsortiumsPrincipleInvestigators
Link Child and Master Fields ConsortiumID
ComboBox on subform
Principal investors
Row source: SELECT InvestorID, InvestorDetails FROM PrincipalInvestors
Control Source: InvestorID
Bound Column: 1
Column Count: 2
Column Widths: 0,2
Some notes on Not In List
DoCmd.OpenForm "AddSomething", , , , , acDialog, AddData
If Forms!AddSomething.Tag <> "" Then
frm(cbo).Undo
frm(cbo).Requery
frm(cbo) = Forms!AddSomething.Tag
AddCombo = acDataErrAdded
Else
AddCombo = acDataErrContinue
End If
DoCmd.Close acForm, "AddSomething"
This is the simplified version of the problem: We have a table on an Oracle Database. We cannot extend this table (bought app). We need to describe each row of that Oracle table with some text.
So the descission has been to use MS Access for this. So I created in Access a table (Call it ACCESS_TABLE). The table consists of ID and MEMOTEXT (and more). The ID is the link to the table on Oracle (Call it ORACLE_TABLE). I have successfully linked up MS Access thru ODBC to Oracle and have both tables available.
My first idea was to JOIN them. But then I cannot do edit. MS Access locks all fields up because of the JOIN with an ODBC table.
Then I thought of creating a form to just edit the ACCESS_TABLE and display the data from the ORACLE_TABLE. This might work but I abandoned that idea also because I want to show the user the ORACLE_TABLE (as the leading table) so that the user knows what rows still need a description.
So I was wondering whether I copy all data from the ORACLE_TABLE and add it to the ACCESS_TABLE. I then have to implement some replication algorithm of deleting/updating rows in the ACCESS_TABLE when they change but this might work. And I wondered how this could be done best.
Also I wondered whether I am at all on the right track or should tackle the problem differently in general.
Why did you abandon the form so quickly? Did you try Oracle as the main form and Access as a subform? It is also possible to have two subforms synchronized, so that subform 1 shows all Oracle records, joined to Access, if required to show whether an Access record exists, and subform 2 shows the Access record for the selected record in subform 1. There is an example in the Northwind sample database (customer ordser form, AFAIR).