I'm trying to implement my own NACE code database, and have found a .CSV file with all the codes and their respective names so that I don't have to enter them all by hand.
Problem is, the codes are all in one .CSV file. Is it possible to dump them[NACE codes] all into one table and then somehow distinguish the parent-child relationships between them all?
So, for example if all the codes are imported into table names "tnacecodes":
J62 - Computer programming, consultancy and related activities
will be the parent of
J62.0.1 - Computer programming activities
J62.0.2 - Computer consultancy activities
J62.0.3 - Computer facilities management activities
J62.0.9 - Other information technology and computer service activities
even though they are all in one table.
What I will do with this is create PHP page with nested links. By clicking on a higher level NACE codes(i.e. J62) the PHP script will retrieve the sub related codes(J62.0.1, J62.0.2,...) and display them on the page.
You can add a column with a parent link for each item. This allows a hierarchical structure (conceptually) in a single table. You can access the children of an item by searching for items with parent links to that item.
Related
I am attempting to recreate in MS Access a personal productivity database that I had in Notion (created based on this https://www.youtube.com/watch?v=32dLXdB4ozs). Basically I have a bunch of things (Projects, Meetings, People, Partners (which are orgs), tasks, etc.) and relationships between then. Each project has partners. Each meeting covers certain projects. People work on particular projects and for particular partner organizations, etc. Lots of these relationships are many-to-many.
I've set up most of the back-end stuff: I have a table for each "thing". I also have tables for each many-to-many relationship. So for example I have a People by Partners table to show which people work for which partners, a Projects by People table to show which people work on which projects. A Meetings by Projects table for which meetings are about which project...etc. etc. i have made each field in this a linked relationship to the other two forms. So for example, the projects by people table has a project field linked to the project page and a people field linked to the people table. I've set all of these relationships to have data integrity and to do cascading updates.
Now I'm creating the more interface-like part, which will be used both for viewing and entering data. So I'm starting with a project form. In the project form, I'm putting a sub-form that will list the partners on that project. I created that form based on this video (https://www.youtube.com/watch?v=N46mgIqLXbA&t=0s) which you probably can't see, but the basic idea is that it's a combo box with the record pulled from the partner table and then the update linked to the partner by project table. I have set this to pick from a list since there are a limited number of partners.
Ok, now here's where I'm running into a problem:
I want to set this so that if I enter a partner name not already on the partner list, it gives me the option to add it as new. I've set it up using this code: http://msaccessgurus.com/VBA/Code/Combo_NotInList.htm . T
he code works fine (* sort of, see next para) if I do it directly to update one of the original tables (e.g. Partners), but I need it to update the Partners by Projects table.. I need it to put in the new Partner name, link it to the currently-viewed project, and then from there update the Partners table (which I thought would happen with the cascading updates).
Instead if I enter info not on the list, it asks me if I want to add it and then when I say yes, nothing happens. It doesn't add. In the form field, it shows me the dropdown list of existing partners to pick from. It tells me there's a syntax error and the error seems to be somewhere in the error proc.
How do I get this set up so I can enter the names of new partners and it will appear correctly as added wherever it should appear? Obviously the partners/projects is just one case where I will need to do this, so i need to figure this out or the whole system can't work!
Thank you for any help. Please note: I am not a professional (or even particularly skilled) programmer. My job is something else entirely and I am a muddling amateur with a basic understanding of programming and database concepts and some minor experience with other programming languages, but absolutely nothing with vb.
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.
I have collected a bunch of crafts and DIY instructionals over the years. Each has a list of instructions and a list of materials needed.
I want to store these in a database, but as I have limited experience I'm questioning the correct/proper way to structure and Design the database for SQL.
Initially I was going to put everything in one table, so each record would represent a project, and then there would be one field for the instructions and one field materials. Each set of instructions would go into one value, perhaps separated by some character or symbol.
However, I'm wondering if it's better to separate the instructions and materials into their own tables (a table for each instruction set for each project). But with this method, there would have to be hundreds of tables if I create a table for each set of instructions for each project.
The third option would be to put ALL the instructions for each project into one table, then give them an id for the corresponding project, and an id for the order they should appear. But this would mean possible duplicates, especially in the materials table (hammer, for instance would appear multiple times, but would have separate ids referring to separate projects). I also worry about the table being too big with thousands of entries.
The fourth option would be to have one table, but add an excessive number of fields for instructions and materials, and only use the ones needed for each project (for example 100 "materials" fields, but perhaps one project only uses 10 and the other 99), but this does not seem proper, and could lead to trouble later on.
Is there a standard way to go about solving this problem, structuring a database for a list of things, which each reference another list of things?
I am currently in the planning phases of developing a multi-user shopping list application for mobile devices. In a nutshell, it will allow a registered user to create shopping list categories and then add individual items to one of these categories. The users' sets of categories and the items underneath will make up their "list." The user will be able to share their list other authorized users. All these users and the list creator will be able to edit/update these lists.
I'm not very familiar with database design although I feel relatively comfortable with mySQL and its syntax from limited use in past projects and web development. From the tutorials I've read, it is important to minimize redundant data, and in order to do so, and also leverage some of the power of relational database systems, I must use foreign keys and reference table(s).
This is what I've got so far, but now I'm stuck:
Essentially my main question is the "list" table done correctly? The way I am seeing this work is that as a user attempts to add an "item", we first to make sure some other user hasn't already created an "item" with the same name; this is to prevent duplicate item text from being stored in the database. If that item name already exists, just toss back the item_id to client program. The same process should occur when a user attempts to create a category. This idea came from my (very) basic understanding of trying to eliminate duplicate objects. If either of these objects don't exist, then they get created in their respective tables.
So now I would add the information to the actual list table. The user_id references which user owns the list, category_id points to a category in the category table and item_id points to an item in the item table. "checked" simply represents whether the item has been checked off the list, but not yet removed.
Is this a tenable design, or should I just start over from scratch? If so, can someone give me some clues as to a better design?