Questions about Sharepoint Lists created by the Access data migration wizard (location, deletion, updates) - ms-access

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.

Related

Preserving relationships when re-linking tables in Microsoft Access

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.)

Organizing a database using folders in phpMyAdmin

Right now I have a database in phpMyAdmin, and off the the side of the screen, it shows the database name, and a list of tables inside the database. It's fine if it's only a couple of tables, but when there's dozens of tables, it gets hard to find the tables I want to edit. I've thought about creating another database to make it easier to organize, but then I'll have to connect using the different database's name and a different user login for the database, and I just thought how much easier would it be if I can make folders or something similar inside the database I already have to organize my tables. I'm wondering if something like this is possible, or anyone know any work-around this issue.
Well, you can't create a database (or folders) within a database; that's just not something MySQL is able to do.
phpMyAdmin has a grouping feature that may help your situation. By default, databases with a prefix followed by _ (a single underscore) will be grouped together, as will tables with __ (two underscores).
Here's an example of how this ends up looking when grouped:
Database:
Table:
If you're able to rename some of your tables, you'll be able to take advantage of the grouping feature to make the phpMyAdmin display a bit more manageable. Of course, this won't change the way other tools display the table list.
The configuration directives $cfg['NavigationTreeDbSeparator'] and $cfg['NavigationTreeTableSeparator'] control the separator used. The relevant documentation starts at http://docs.phpmyadmin.net/en/latest/config.html#cfg_NavigationTreeEnableGrouping and includes the next few line items.

MYSQL - best Data Structure

I’m currently developing an Application for Win, Linux Mac. The Purpose of the Application is that multiple users are able create Projects based on a single Article. Every Article has up to 15 different Fields/Options (could also be more in future). The Fields of the Article should be changeable so I should be able to add, edit or remove them.
Fields I want to store:
Numbers
Texts (mostly options [1 Word], sometimes Comments [some sentences])
Path/Links to Files
What I want to do with the dB:
load all projects of a user at login
add, edit, remove, delete single projects
set a lock on projects (because multiple people are operating one user-account at the same time and therefore they may not be allowed to edit a project at the same time so if one starts editing it should be locked until he's saving, channelling or time-out)
What is the best way to manage this kind of Data?
Should I create a Table for each user and only make a ID Column and one where all the Values of the all the fields (who are merged to one big string)?
Should I create Tables for every Project and make Columns for every Field/Option and also one for the user / owner?
Or are there any other possibility’s?
If you don't know what you are going to store, then I doubt whether a relational database is the best option for you. Maybe a document store/noSQL database is a better decision, because you can just store documents (usually in the form of Json objects) that can have all kinds of additional fields.
A couple of such databases to look at are MongoDB, Cassandra, ElasticSearch, but you can find a big list on Wikipedia.

phpMyAdmin Tables vs. MySQL Views

What, if any, is the difference between MySQL views and the way that phpMyAdmin shows its tables? When I created a view on phpMyAdmin by clicking "Create view" under "Query results operations" under "Browse" in a table:
,
the created view looked exactly like the view shown in the "Browse" window for that table:
I am more talking about visual style here, I know that since I used the defaults the table includes the same columns/rows. Do all SQL views look the same, visually, as phpMyAdmin tables as shown in the GUI? Is that some sort of standard, or just the way phpMyAdmin does it, and others could be different?
Is it possible to create views in the browser, or are they just created on the server for the convenience of the developer? W3schools doesn't have a syntax-testing tool for views, which makes me wonder, as they have one for pretty much everything else.
I am using phpMyAdmin 4.1.5.
You are asking about visual style. Neither tables nor views have a particular style. The tool you use -- the command line, PHPMySQLAdmin, MySQL Workbench, or whatever -- can display them however the developer likes.
For convenience, views and tables will likely look very similar or the same in most tools, because they have similar structures (but not the same functions or purposes). But how they look is up to the developer of the tool.
If you do not do anything else, a view of a table will be the same as the table itself. You might create a view of an employee table called phonebook that had only name, office number and phone extension. The employee table might only be readable by the HR director while the phonebook view would be accessible to the entire company. In this case the view has fewer columns than the underlying table.
Or you could join the employee record with the department record that he is assigned to and create a view with more columns than are in the underlying "employee" table. It sounds like you just took some default options and created a view that was just like the underlying table. It is ok for a start, but now drop the view that you made and recreate it with some purpose in mind and you will see the differences when you browse it in phpmyadmin.

Adding tables via DAO to a database

As a general question which would really help me "connect the dots" with my studies.
I am currently doing exercises working with DAO and Learning how to add tables automatically. Although i have been working with databases for many years, i question, what type of scenerarios would it be vantagious to use this function. When is it necessary to add tables to a database in an automatic way? Up until now, in all my experiences the tables i need have Always been defined from the beginning and I cant think of a situation where I could of benefited from using this function. For example, i use frequently delete queries to help me clear tables and re-populate them, but when would it be necessary to actually "create" a new table"?
Yes, I have seen a scenario where new tables were created 'on the fly' (either via SQL create, or just DAO). With a shared database on a server, the application called for importing Excel data that a particular user was responsible for, so a table was created on the fly. Multiple users, changes in staff, need to keep data independent, etc. we could create their own table (name based on userid) that they had interfaces to do whatever they wanted with their own data. Not a typical scenario, but worked well for this application.