In my Microsoft Access 2013 database, I have 3 Call Detail areas in which I can document the outcome of calls to potential new customers. The final step in the 3 details, is an outcome displaying what the call generated. I would like to avoid the word "Booked" being duplicated in the 3 outcome fields I have.
The 3 fields I want to prevent "booked" duplication are respectively named; [outcome1],[outcome2],[outcome3]
Normalize the schema and you can use an index constraint. The outcomes should be in a separate table related to the call table with a foreign key. Once you do that you can be sure no duplicate outcomes are tied to the same foreign key.
BTW, one outcome attribute per record. Not three attributes that mean the same thing but are named differently in one record.
Related
The database i'm trying to create have four tables. tblPatient information, tblparasitology tests, tblserology tests and tblbiochemical tests. All the later three tables are related to patient information table. What i want to ask is that, is there a problem if i use the primary key in the table patient information to foreign keys of all the other tables? in other words how many tables (foreign keys) can be related to a primary key on one table?
There is really no practical or particular limit here.
however one tip, one concept to keep in mind?
While you can setup all these related tables, to create forms that edit the data?
Each form is STILL based on the one base table.
So you can create a form based on tblPatients.
So allow view and editing and adding of say tblserology results?
That will become a sub form. NOTE VERY careful here that the form tblPaitent is based ONLY on that one table. And the child table (and child form (ie: sub form) tblserology will ONLY be based on tblserology table. So the forms to hook up, wire up the relatonships between the tables are STILL only based on the single table.
To allow editing of related data, you thus use sub forms. If you do this correctly, then no code is required to edit and display and maintain say display of test results for a given patient.
So each and all tables will have a primary key (auto number id).
To realate a child table back up to a parent table, you create a plane jane long number column. This value will be automatic setup for you if you follow the above advice for a main form, and then a sub-form for the child table data.
I am working on appending some additional data from an Excel spreadsheet to an existing Microsoft Access database. The primary key is "RecordID", however, when I go to create the one-to-one relationship between a current table and the new table with enforced referential integrity, I am receiving the error message, "Microsoft Access can't create this relationship and enforce referential integrity". The weird thing is I went through and compared every single RecordID between the two tables, and they match 100%.
I then ran a "Find Unmatched Query" to compare the two tables' RecordIDs, and 5 RecordIDs appeared. However, they LOOK like they exist in both tables. For example, both table 1 and table 2 contain "ST101_1", but "ST101_1" was listed in the unmatched query.
Even stranger, I then opened table 1 (the master table), and for those records listed in the unmatched query, I tried to add a duplicate record. It shouldn't let me do this because "RecordID" is the primary key. However, again, for those records listed in the unmatched query, it allowed me to enter a duplicate value. For example, under "RecordID", I typed "ST101_1" and then added a new record with "RecordID", "ST101_1", and it did not give me an error message that I am entering a duplicate value!
Any input is very much appreciated - this is driving me crazy!
Relationships (the newly imported table is tblFreesurfer, which I want to connect to tblRecordID with enforced referential integrity) 1
Result of unmatched query between tblRecordID and tblFreesurfer 2
Image of my front-end, and database allowing me to enter what looks like the same RecordID 3
You have to post your table desings and relationships.
However, some unmatched query is just that - a query. Such a query can operate on any table.
You have to pick + assume that you have a master table. Of course you can add lots and lots of new records without having a record in the child table. (because you can't add two records at once!!!).
However, if the PK of this main table is in fact set as a PK, then you cannot enter the same PK value more then one time. If this is the case, then I suspect that the data being imported has trailing blanks, as this is not possible. Either your setup is wrong, or the imported data has trailing blanks. I would bring up two records with the SAME pk, and place my cursor in one of the columns, and hit f2 - you see the value in the field highlight, and you see extra spaces. While editing from Access you can't enter trailing blanks, you can with code, or during a import.
Issue:
I am developing a simple issue tracking database and have hit a stumbling block that I’m not sure how to resolve. Have tried several approaches using queries, sql statement etc but still not working. I may have to rethink how I am doing this but hoping someone may be able to address the issue as it stands, though if a more elegant way of doing it happy to implement that.
Scenario:
A table called tblUsers has a field called Access that is a lookup to a table called tblCategory and allows for multiple values to be stored (one to many). In essence this is saying which category(s) of “issue” the user is allowed to
A simple msgbox test in code shows that this is correctly storing the values selected in the following format "1, 2, 3, 4"
In turn, each issue can only have a single category (one to one) which is stored in a field called Category in table tblGMPIssues and is also populated from a lookup to the tblCategory table.
So far so good ….
I then have a query called qryUserIssues that should show all issues from the table tblGMPIssues that are a) “Open” (status = 1) and that b) match any of the categories that the user is permitted to view.
I can get this to work with a single value i.e. as it stands query prompts for input and if you enter a single valid integer it returns expected results
But I can’t work out the syntax to get the criteria to accommodate multiple values. For example, in above scenario our user should be allowed to see 4 different category or calls “1, 2, 3, 4”
Tried using INNER joins, tried assigning to variables and using a LIKE criteria but can’t seem to get the syntax right.
If anyone could let me know if this can be done and if so how as it’s driving me nuts.
All help and suggestions gratefully received.
Updated relationship diagram --> 1
For precisely the reason that you've asked this question I would recommend never using the multi-select lookup option for columns in MS Access tables. Instead create an intersection table which tells you the combinations of values from the two main tables that are allowed. So instead of having the multi-select Access column in tblUsers, you should have a separate table called tblUserAccess with two columns (UserID and CategoryID). The two columns together will form a composite Primary Key for this table, and individually they will be Foreign Keys to tblUsers and tblCategory respectively. (You should do the same kind of thing with tblType - remove the Categories column and set up a separate table called tblTypeCategories).
Coming to your query, are you expecting this to show you all the relevant Issues for a particular user? At the moment, it is not doing this. The reason it is prompting you for input is because it doesn't understand ([tblUsers].[Access]) - tblUsers is not referenced in your query, and the query has no way of knowing which particular user you're interested in.
With your new table in place (and populated with the relevant data) you should add tblUserAccess to the query, joining tblGMPIssues.Category to tblUserAccess.CategoryID. Take the ([tblUsers].[Access]) condition off the Category column. Add the UserID column to the grid and set the criteria to [Input UserID]. Now when you run the query it will ask you for a user ID, and it should hopefully show you all the Issues that the given user can access.
Good luck!
First, I suggest you normalize your data a bit:
You have a number of tables that are reference data (e.g. tables tblStatus, tblSeverity, tblLocation). You have a s a primary key a (system generated) ID. That is wrong! The primary key of these should be their data, i.e. status, severity, location.
I can't see what the relationships are between the data. It should be one-to-many, mandatory (i.e. one Status can occur in many tblGMPIssues and a status is mandatory).
Your table tblType is unclear to me but it contains the categories. I am not familiar with the '-' before Categories followed by a Categories.Value but I assume an occurrence of tblType can contain exactly one Categories.Value. If not, then you must decompose this table.
If a User has access to a number of Categories, then there must be a many-to-many relationship betwen Users and Categories. From this relationship you do your select query, but I don't see this relationship.
Use following query to get any of the Category IDs 1, 2, 3 or 4
Select * from tblGMPIssues where tblGMPIssues.Category in (Select UserAccess from tblUserAccess)
I still have many problems with your relational design, or actually the lack of a proper relational design. As an example, below is a diagram from my Access 2007 showing a part of your database with a proper design. Access automatically shows that "one" and "many" symbols (which I don't see in your diagrams). I also show the relationship dialog with the proper fields checked. Note that none of the keys of any table, except tblIssue, has a system generated primary key. They are all plain text whch allows better understanding when inspecting the data and, as said, the database automaticlly updates child tables when the primary key value of a parent table changes.
Note table tblCategoryType: it implements a many-to-many relation between categories and types, meaning a category can be of zero or more types and a type can be in zero or more categories. In addition to "update cascades", this table has the "delete cascades" checkbox checked so if a category is deleted, all its relations with types are deleted (not the types).
I am looking for the standard way to handle the following Database Situation.
Two Database Tables - One called Part, one called Return. In Part we have information about Part Number, Cost, Received Date, etc.
Return is for if that part is being returned to the vendor. It will have Return Tracking Number, Shipped Date, and If Credited.
A Part can only have one Return but may have none if Part is not returned to vendor.
The 3 options I see are:
Put both Part and Return in the same Table but I do not like this idea, table will get too large.
Create a field in the 'Part' Table to reference the Id of the Return record that it is related to. My Concern here is there could possibly be free floating Return records not attached to a Part
Create a field in the Return Table to reference the Id of the Part record it is related to, making the PartId field unique so I cannot duplicate Part Id.
Is there any advantage or disadvantage to using #2 or #3 (or I guess #1 if that is a viable option)?
UPDATE:
I should have mentioned in reality these tables will be much bigger, and in the application I will be viewing Returns and Parts information in seperate views.
Basically you have 2 entities, Part and Number with 1-1 relationship where one entity is optional.
In this case you should create a table for each entity (i.e. 2 tables) and use the PK of Part as a reference in the Return table. That is the standard way to represent relationships of this kind.
solution 3:
with the exception that you do not need a unique constraint on part_id, just make it the PK (which is almost the same)
So the root of this problem may lie in poor database design, some of the way this is set up is inherited from older versions. I just couldn't figure out a better way to do this.
I have four tables linked by the same field: [OBJECTID]. Each table is linked to an Access Form that controls the data. It is important that these tables be separate as the data is georeferenced and needs to be mapped separately, however they inherit several fields from one another by default.
Most of the time, the tables are in a one-to-one-to-one-to-one relationship, however occasionally, there is only data for the first table, and occasionally, there is only data for the second, third and fourth form.
Right now, the [OBJECTID] field in the first table is set to datatype autonumber, so that all subsequent linked records in the other tables can inherit that number. For the cases where the record in Tbl1 are not entered via Form1, it is easy enough to just assign a number that does not conflict with any current number, but how do I avoid assigning a number that could conflict with some future [OBJECTID] generated by the autonumber field in Tbl1?
Sorry if that is confusing! Thanks in advance for helping me think this through....
If the design is correct, there should be a relationship with referential integrity between tbl1 and table 2/3/4. Since you mention that occasionally, there is only data for the second, third and fourth form that means we have no referential integrity here :-/.
I would identify the fields that are common to all 4 tables, and create a "main" table with those, meaning that the main table MUST be filled. Then you create a 1 to 0,1 relationship to the other 4 tables, with an outer join, their PK beeing then a Long Integer.
For the source of your forms 1 to 4, use an outer join between MainTable and T1/2/3/4. The "subtables" will then inherit the PK of the main table.
Hope I am not too obscure.