I have been tasked with create a tracker for company work flow.
I have 10 tables with data in them. There are attributes all the tables have in common. I made a table with those attributes, giving those records a unique ID that could join them to the unique attribute records of the original tables. I am also linking a personnel table to the original tables. All of these tables exist on my SQL Server back end. I Have made a query in Access that displays all the information I was given. I'm going to use the forms in access as a front end to display, edit, and add records.
The issue I am encountering is that I can not write to a query that has externally linked tables. I have spent a lot of time normalizing this data and I know I can get around it by making tables with redundant attributes in SQL and not writing to the query, but rather write to the linked tables instead. Just wondering if there is a way around this.
Thanks
In general, even without linked tables, such queries are NOT updatable.
The general approach when working with multiple tables is to use sub forms for the child tables. That way, each form is only bound to one table. (You are free even to bind such forms directly to the linked table).
Thus, you might say have a customer table and then a table of invoices. So your main form will display the one customer and is bound to that one table.
In the sub form, you can then display all of the invoices.
So to combine multiple tables into a form or screen that allows users to update the data, or add more data, you don’t build some query that joins all the data together, but simply combine several forms into one form. But each of those separate forms will display data from the given related child table.
Here is a typical invoice form thus built in Access:
The top part is the “main” form of an invoice. It is bound to the customer table – one record. Then the multiple lines of detail is the invoice details table. So the form does NOT use queries, but each part of the form and sub forms are bound to the given related tables. You are binding each form directly to the linked table (or tables if you need to show related data like above).
This approach allows you to cobble together a set of forms that edit related tables, but each form is bound directly to the linked table.
So the fact of linked tables or not is moot – such queries are not used to edit data and such queries from link or non-linked tables are NOT updatable.
So your form + sub forms will follow the pattern of related tables that you need to work together as one whole view and means to edit data. You don’t need nor want to use a query to fill these forms.
You most certainly will provide some kind of “search” form, or some means to pull up say one customer invoice, and that invoice along with its sub forms will display the related data, and also allow editing of that data.
Related
I have a contact database, created on SQL server. An example of its many to many relationships is below:
1- Contact table (ContactID, Fname, Lname, ...)
2-Contact_Skill table (ContactID, SkillID, Score)
3-Skill table (SkillID, Skill_name, Skill_type)
For easier interaction, I linked this databse with MS access file (which will be the interface, used by users). Users mainly use it for insertion, and I have somewhere else a SQL report server to retrieve some data and do some reports.
My issue now is that, I'm trying to find an easier way (without programming) to insert data in the intermediate table (Contact_Skill), other than getting the IDs manually. A thing like a drop down menu, that enables the user to choose the skill and it turns into its ID. Any easier way would be so welcomed as well. Thanks
Ok, you likely don't need code, or at the very least VERY little code, and you certainly don't have to write code to insert the records.
So, I would create the form (bound directly to the linked contact table.
So, you can use ctrl-f, or whatever to search, find, jump to your record you want to edit. (so built in search features will suffice for now).
In that form, you will drop in a sub form. (a continues form - multiple items would work nice here.
So, in that form you have this:
In this example, I have
customers
Invoices
Invoice details
So, really, I have near example the same kind of setup. One master table (customers)
Then a child table of invoices.
And then for each invoice, we have details of the invoice.
So, your main form will have that sub form dropped in that shows the contact skills.
In my case, I have this:
So, for this, you not really written any code.
Now, do note that for each invoice (or your case of contact skills).
Note how I have a edit button in that continues form.
This allows our "drill" down.
The code behind this button is:
if me.Dirty = true, then me.Dirty = False
docmd.OpenForm "frmInvoice",,,"ID = " & me!id
So, clicking on edit will launch a new "main" form based on invoice (or in your case skills) the ONE record.
Now for that skills record, it not clear if you have another drill down (child table), but lets assume you do!
so, In that form, you simply drop in another sub form (again continues items), and you thus are now free to add more skills to that one contact skill.
In my case, it is invoice details, so we have this:
The above screens are rather crude (they are test scenes), but it shows a design in which you dealing with 3 typical related tables.
So the whole system works with about 6 lines of code. Just keep in mind that when you drop in a sub form to relate child items? Access will setup the foreign key value that belongs to the parent table that has the one "main" record, and that sub-form of child records. All that is required is that the link master/child setting is setup correct. Once done, then Access will manage and set the correct values used to relate the tables to each other, and you don't have to write any SQL or even any code for that matter. (you are free to add a sub form record, and then hit Edit button for further details to edit, or as noted add more child records to that form you just launched.
So related tables, and adding of child records is VERY automatic in Access, and you don't write code to add the records - access will do all this work for you if you follow the above design pattern. About the only code you ever had to add is the the "edit" button to launch the next form in the sequence.
So I've done extensive searching on this and I can't seem to find a good solution that actually applies to my situation.
I have a list of projects in a table, then a list of people. I want to assign multiple people to one project. Seems pretty common. Obviously, I can't make multiple columns on my projects table for each person, as the people will change fairly frequently.
I need to display this information very quickly in a continuous list of projects (the ultimate way would be a multiple-select combobox as a listbox is too tall, but they don't exist outside of the dreaded lookup fields)
I can think of two ways:
- Store multiple employee IDs delimited by commas in one field in my projects table (I know this goes against good database design). Would require some code to store and retrieve the data.
- Have a separate table for employees assigned to projects (ID, ProjectID, EmployeeID). One to many relationship between projects table and this new table. One to many relationship between employees table and this new table. If a project has 3 employees assigned, it would store 3 records in this table. It seems a bit odd joining both tables in this way, and would also require code to get it to store and retrieve into a control like the one mentioned above).
Does anyone know if there is a better way (including displaying in an easy control) or how you usually tackle this problem?
The usual way to tackle this problem would be with a Junction Table. This is what you describe where you have a separate table maybe called EmployeeProject which has an EmployeeProjectID(PK), EmployeeID(FK) and ProjectID(FK).
In this way you model a Many-to-Many relationship where each project can have many employees involved and each employee can be involved in many projects. It's not actually all that difficult to do the SQL etc. required to pull the information back together again for display.
I would definitely stay away from storing comma-delimited values as this becomes significantly more complicated when you want to display or manipulate the data.
There's a good guide here: http://en.tekstenuitleg.net/articles/software/create-a-many-to-many-relationship-in-access but if you google "many to many junction table" or similar, there are thousands of pages/articles about implementation.
I have a report i need to create that has a severe performance problem.
I need to create a catalogue of all courses in our database.
Here is the simplified data model:
Organizational Unit --> contains multiple Courses --> which contains Multiple Activities;
Each activity contains the following:
A list of attached links
A list of prerequisite activities
A list of additional property - value pairs (Cataloging information)
A list of required resource types and quantity for each resource type
A list of Training Objectives
and I wish to create a report that will group everything to look something like that:
After creating the straightforward query which joins all tables together i got almost 6 million rows because of different cartesian products that occur due to joining the activities table with all the 1-many relation table for getting the attached links resources etc...
I was thinking to avoid that in several ways:
sub reports that will list the different lists of items foreach activity.
create an XML field foreach of the described above lists and parse it using VB in my report
use multiple datasets in the report and somehow use lookup functions to list the different values.
Results so far:
sub-report proved to be very inefficient with regards to performance and it took 50% more that what it took with the original 6 million row query.
the xml fields are very efficent DB-wise but it will be trouble to format the data using VB i would very much like to avoid that if possible,
I cannot seem to find the right way to use lookupSet to get a list of attachment names and their links next to them.
so my questions are:
what is the best practice when displaying an entity with a lot of 1-many relations that need to be displayed when dealing with a lot of data and SSRS 2008-r2.
is there a way to join data using lookup function and somehow create "nested tables" that will list 1-many relations
any other suggestion would be very appreciated.
Can you create a drill down report? This looks like a good option to have activities listed and the courses being summarized and then drillable with the detail separated, or similar.
Or you can cache your report if the data change is unimportant?
6m records is a lot for a ssrs report!
If i want to add a record to TABLE A, is there an efficient way to add
a record in the JOIN TABLE for many (or all) records in TABLE B?
I try to build a simple task management (in CakePHP). An user adds a task and there
will be added a connection to each other user in the same group as the
current user.
At the moment, I use the find('list')-method to retrieve the IDs and
store them in a variable. But I think if the groups grow, the PHP
cache won't handle this amount of data in a single variable.
You should look into the Cake Has-And-Belongs-To-Many (HABTM) relationships. Check the cake book. It will allow you to create a relationship between two tables, using a join table, and will automatically retrieve and save values as requested in your application.
Please note, however, that from one model you cannot (by default) filter by criteria on the related model (in this case, the model related by the join table). To do this, you will need to use the Containable behavior, which will allow you to set filter criteria on the related tables.
The one other caveat is that I don't know of a way (out of the box) to add some information about the relationship in the join table. For example, if you wanted to record (in the join table) whether the user has completed the task, you would have to write your own stuff there. I usually get around this by creating a model for the join table, which I then invoke whenever I want to retrieve data specific to the joined relationship. By doing it this way, you can also easily pull up the data from the joined tables. Anybody else have a better solution?
I have a SQL Server as backend and use ms access as frontend.
I have two tables (persons and managers), manager is derived from persons (a 1:1 relation), thus i created a view managersFull which is basically a:
SELECT *
FROM `managers` `m`
INNER JOIN `persons` `p`
ON `m`.`id` = `p`.`id`
id in persons is autoincrementing and the primary key, id in managers is the primary key and a foreign key, referencing persons.id
now i want to be able to insert a new dataset with a form in ms access, but i can’t get it to work. no error message, no status line, nothing. the new rows aren’t inserted, and i have to press escape to cancel my changes to get back to design view in ms access.
i’m talking about a managers form and i want to be able to enter manager AND person information at the same time in a single form
my question is now: is it possible what i want to do here? if not, is there a “simple” workaround using after insert triggers or some lines of vba code?
thanks in advance
The problem is that your view is across several tables. If you access multiple tables you could update or insert in only one of them.
Please also check the MSDN for more detailed information on restrictions and on proper strategies for view updates
Assuming ODBC, some things to consider:
make sure you have a timestamp field in the person table, and that it is returned in your managers view. You also probably need the real PK of the person table in the manager view (I'm assuming your view takes the FK used for the self-join and aliases it as the ID field -- I wouldn't do that myself, as it is confusing. Instead, I'd use the real foreign key name in the managers view, and let the PK stand on its own with its real name).
try the Jet/ACE-specific DISTINCTROW predicate in your recordsource. With Jet/ACE back ends, this often makes it possible to insert into both tables when it's otherwise impossible. I don't know for certain if Jet will be smart enough to tell SQL Server to do the right thing, though.
if neither of those things works, change your form to use a recordsource based on your person table, and use a combo box based on the managers view as the control with which you edit the record to relate the person to a manager.
Ilya Kochetov pointed out that you can only update one table, but the work-around would be to apply the updates to the fields on one table and then the other. This solution assumes that the only access you have to these two tables is through this view and that you are not allowed to create a stored procedure to take care of this.
To model and maintain two related tables in access you don’t use a query or view that is a join of both tables. What you do is use a main form, and drop in a sub-form that is based on the child table. If the link master and child setting in the sub-form is set correctly, then you not need to write any code and access will insert the person’s id in the link field.
So, don’t use a joined table here. Simply use a form + sub-form setup and you be able to edit and maintain the data and the data in the related child table.
This means you base the form on the table, and not a view. And you base the sub-form on the child table. So, don't use a view here.