Once upon a time, you could take a set of tables in Access re-link them to a new database (test to production, for example) and it would preserve the table relationships. As of the latest change to Access 2016, relationships are removed when you do this.
The way access works in this regards has not changed in 20 years.
To create a table, or index, or relationship? This is ALWAYS done in the back end. The act of "linking" does not change or even touch anything in the back end database that you link to.
And you can't change or modify relationships in the front end. What would happens if 3 different people linked to the same back end? (could they all have different relationships setup? If that could occur, then no type of enforced relationships would be possible in access.
As a result, any display of the relationships between tables in the front end that is doing the linking amounts to NOTHING MORE THEN A PRETTY PICTURE!
In other words, if you link, then access may or may not show the relationships in the relationships windows. Regardless of what is displayed, the viewing, the changing, the setup of relationships is ALWAYS done in the back end - what the front ends have or display in the relationships windows is 100% ignored, does not matter, and is not used.
You can for kicks and fun add tables in the front end for your viewing pleasure, and as you drop in tables, access will usually display the relationships used, but they only amount to a pretty picture. Because as noted, many different front ends can link to a database, then who or what would be controlling the relationships if they could be all different? As noted and as result, what Access front ends show and display is 100% ignored by the front end. There is no concept or need of a relationship between linked tables in the the front end. If you do manage for your fun and games to have tables displayed in the front end (relationships window), then it is simply for fun and your viewing pleasure.
Those font ends have zero to do with setting up relationships.
If you use the Access UI to link to a back end and the links are NEW, then in most cases Access front end will show the existing relationships. If you messed around, or cleared out the front end, then re-link will not always show the tables. You can simply add them or delete all your table links and then simply re-create the links.
No matter which means you use (some code, or the built in UI), the display of the relationships in the front end is moot, does not matter, and is not used by Access. The ONLY relationship window that matters is when you open up the back end database and define and manage relationships from that window - all front ends and what they show or have or do not have are 100% ALWAYS ignored and for any linked table the front end DOES NOT matter.
Edit
As a general rule when I do link tables to a front end, launching the relationships windows does (should) show the existing relationships. However, as I noted, it only amounts to a pretty picture - it does not effect or change the actual relationships in the back end.
However, as pointed out in the comments? If you do have a defined relationship(s) in the front end? When you build a query, they will be used for the default join between such tables - and as pointed out, this can be a time saver. So it is fair to point out and admit on my part that you get somewhat "more" then just a picture - you do get default joins when using the query builder.
Use the External Data -> Relink External Tables path to relink tables. After selecting a data source and editing it to change from test to production or vice versa, use Refresh to relink the tables to the new location. Do not use Relink.
(The Relationship diagram is important to our users for building ad hoc queries. It is not just a pretty picture.)
Related
I have years of Access programming under my belt, with either Access or SQL back ends. I'm volunteering my time to help a small nonprofit build a volunteer database. We are forced to use SharePoint Lists as the data backend.
Our first migration using the Access wizard worked but messed up the data because I had not created all the required relationships prior to upsizing. I did my homework, and we tried again. But even though we created a folder for all those files, the Access wizard put the lists at the root of the SharePoint file, and now they are mixed with the first round of tables, as well as other folk's stuff. So, my questions are:
Can we specify where those SharePoint Lists are stored beyond the root directory? (I worry that others may inadvertently edit those lists...)
How do I delete the lists? It says we cannot because relationships are set
How do I in the future alter the lists (like altering tables in SQL?) I know I'll need to add columns eventually.
I've searched MS and here, and MS solutions are crazy simplified, so they don't answer my questions. TIA!
Can we specify where those SharePoint Lists are stored beyond the root directory? (I worry that others may inadvertently edit those lists...)
Yes, go to the SharePoint site. From ONLY the Team site, create a sub site.
(regular sites don't work - MUST BE A CHILD of TeamSite).
You can up-size the access tables to that site.
So, just like creating a folder, or in this case a site?
Say you create a new teamsite (MUST be subsite - so crete a subsite to teamsite) called Customers. Then you can specify that target for the database. As noted, since the access table features are "special", only sites created as sub sites to TeamSite(s) will work.
So, it stands to reason that each database should get its own site (perhaps better term is sub-site). Then you can up-load/up-size a database to that one team site you just created - and all tables are thus "grouped" or part of that "one" site or URL.
So say we have a database called customers - then we create a (sub) site called customers. Your url would thus be "something" like this:
https://myCompanyName.sharepoint.com/TeamSite/Customers
How do I delete the lists? It says we cannot because relationships
Well, actually, even in Access regular tables - you as a general rule can't delete a table that is part of a related set of tables. This suggests then you have to delete the relationships first.
Display the site contents,
right click on the child table that has the related column
(choose settings).
You now are in the "settings" for that one table/list.
You can click on the column that has the relationship.
You see this:
So, you can remove the relationship. (scroll down to bottom).
And if those tables are LINKED from access?
You can use the table view in Access - and change/add columns - you do NOT necessary have to do this from the web interface.
How do I in the future alter the lists (like altering tables in SQL?) I know I'll need to add columns eventually.
You can do this from Access or SharePoint - Access side is better choice.
if the table is linked from Access, then use the table view. You not be able to jump into table design mode - but if you open a table, you see this:
And while in above I am on the last (add new) column, if I wanted to say change or add a index to say FirstName column? I could do this on SharePoint, but you ALSO can just click on any column - note the ribbon now:
So, all this is quite much basic SharePoint stuff.
But, open the linked list - you can add new columns, or remove columns - the above ribbon options show the options you have (such as index, etc.). And like always, to delete a column, in that table view from Access, right click - you have this option:
So, you add, or delete fields BOTH from the SharePoint site, or from the above table view in Access.
I am struggling with an issue in designing my Access database.
I am a caregiver, and part of my job is taking clients out into the community. I am attempting to build a catalog of outings to help the employees at our company come up with and store ideas for these. I want to store information for each of up to 5 types of events that clients can do at a location. That information includes the event type, when it runs and doesn't, and how much it'll cost, all of which would be user-selectable. (Separately in the same table, I want to include contact information and information that helps the user search for event locations, such as the ZIP code.) I have attempted to normalize the database by spreading event information across fields in the main table, linked to lookup tables. I am aware that Access has a limit of 32 relationships per table.
To help staff find event types, I am trying to set up a method for categorizing them. That requires setting up nested lookup tables, as shown in the first picture.
If I understand correctly, the additional "copies" of those lookup tables are aliases. When I save the setup for the relationships between those aliased lookup tables, close the Relationships window, and open it again, I find Access has changed them, as shown in the second picture. This happens whether I delete the lookup table information for each field in Datasheet View. I don't understand why it does this or how to fix it.
To answer your question:
In the object browser I see that you have only one table: t_OutingType. Therefore, the "tables" t_OutingType_2, t_OutingType_3 are just aliases; "pointers" to the same table (like a shortcut to a document). When you save the relationships and close the window, the relationship information is written to the metadata of the database. When you re-open the Relationships window Access re-builds the relationship diagram from the metadata, and it does not include the redundant aliases.
Additional advice:
Whenever you find yourself duplicating columns in a table, e.g., Event_1, Event_2, ... a little voice in your head should start shouting "Are you sure that's a good idea?" Imagine if you want to search the database for events that fall on a certain date. With the table layout described above you would need to ...
SELECT ... WHERE EventDate_1 = [theDate] OR EventDate_2 = [theDate] OR EventDate_3 = [theDate] ...
It's almost always better to split the Event information into a separate child table and maintain an association table between the child table and its parent.
The Django docs say you can put a many to many field in either side's model, but not both. Example showing Pizzas and Toppings says it's more "normal" to think of the toppings on a pizza than think of which pizzas a topping is on, so put the field in the pizza model. OK...
However, in my application which tracks permissions and groups, this is not necessarily true. The application has a many-to-many in the permissions table showing which groups have that permission. It also seems like you should be able to look at a group and see what permissions it has. This would theoretically use the same join table.
Couldn't I add a many-to-many-through field in the groups model and specify the existing permission_group join table? Would this cause problems, as it directly violates the recommendation in the ManyToMany documentation?
Thanks...
I can't really see the reason for it. It doesn't matter which end of an electrified wire you touch - the end result is the same. What happens on the database level is exactly the same with no regard to where you add the field in Django. You can still do reverse lookups from either side (check out documentation about related_name setting, it's handy) so you can get both
a) all persons with some specific permissions
b) all permissions that a user has
If you try what you propose, you will end up with two parallel M2M fields if Django allows that - and I imagine it does, but that doesn't make any sense at all. It's like talking to the same person over two phones at the same time - why would you do that? Don't.
And as Patrick mentioned, Django has a comprehensive permissions system so you might just want to check that out and maybe it will suit your needs without any effort on your part at all.
You're making a distinction where there is none. The point of a many-to-many is that it is automatically accessible from either side of the relationship; Django does that for you. The point the docs were making was that the difference is a semantic one only; in the case they mention, toppings belong to pizzas. But even doing it that way, you can still access the pizzas from each topping.
Is there a way to visually represent the tables in a sql database; showing relationships, if there are any, between the different tables? Thank you.
In SQL server, under the database name is a folder named "Database Diagrams". Right click and "add new database diagram".
Click on the tables you wish to include, then hit the "Add" button.
Provided you have already setup your relationships the connections will be shown, 1 to many, many to many, etc. You can name and save, then if you add relationships after the fact, they will automatically appear (but if you add tables after the fact, you will have to manually add them to your saved diagram(s)).
You can move the tables and relationship chains around to make it more clear, and add labels for headers, etc. If you have a lot of tables I find zooming out while working on arranging things in a logical order easiest.
Use database diagrams. Here is a link that may help: http://www.mssqltips.com/sqlservertip/1816/getting-started-with-sql-server-database-diagrams/
I'm writing a CMS for various forms and such, and I find I'm creating a lot of drop-downs. I don't really feel like mucking up my database with tons of random key/string value tables for simple drop-downs with 2-4 options that change very infrequently. What do you do to manage this in a responsible way?
This is language-agnostic, but I'm working in Rails, if anyone has specific advice.
We put everything into a single LookUp table in the database, with a column that mapped to an enum that described which lookup it was for (title, country, etc.).
This enabled us to add the flexibility of an "Other, please specify" option in lookup dropdowns. We made a control that encapsulated this, with a property to turn this behaviour on or off on a case-by-case basis.
If the end user picked "Other, please specify", a textbox would appear for them to enter their own value. This would be added to the lookup table, but flagged as an ad hoc item.
The table contained a flag denoting the status of each lookup value: Active, Inactive, AdHoc. Only Active ones would appear in the dropdown; AdHoc ones were those created via the "Other, please specify" option.
An admin page showed the frequency of usage of the AdHoc values, allowing the administrators of the site to promote common popular values into general usage (i.e. changing their Status flag to Active).
This may well be overkill for your app, but it worked really well for ours: the app was basically almost entirely CRUD operations on very business-specific data. We had dozens of lookups throughout the site that the customer wanted to be able to maintain themselves. This gave them total flexibility with no intervention from us.
You cold have one single dropdown table with an extra column to say what the drop down is for... limit the results with a where clause...
At my current position, we implemented a LookupCode table that contains a CodeGroup,Code, and Meaning column, as well as some others (like active). That way you have a single table that contains all of your lookup values are in a single location and you can do some quick lookups to bind to your dropdown lists.