I'm working on Access Microsoft 365. I have a table with 3000 entries, one of the fields is called "Artist" (includes the name of the artist). I've decided to turn this into a Lookup field, and make a table of the Artist names (so that they are all spelled correctly and the user can't misspell a name). Since the data is there already, how can I ask Access to use the data that's there and compare it to the Artist table (hoping that it's a match)? Everything I've tried deletes the Artist Name from all 3000 entries.
I advise not to build lookups in table. Just build combobox on form.
Do a Find Unmatched query to identify records in your data that do not have a match in Artists table. Access has a query wizard for that. Manually correct spelling for any bad records located.
You can save the artist name into your data but a better alternative may be to replace the name field in your data table with a number field for storing ArtistID. This will involve an UPDATE action SQL using a JOIN of the two tables on the name fields. Once the new foreign key field is populated, delete the unnecessary name field from your data table.
Related
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.
I need to move a table from within an ms access database to a SharePoint list. The table I need to move has had old records removed that has ID's auto increment. I need the SharePoint list to start from the same auto increment number as in the table.
I have tried using the ms access export to SharePoint list functionality but when I re-import the table back into access as a linked table to a SharePoint list the ID has started back at 1 (not 81 like in the table I uploaded to SharePoint).
I need the table to upload to the SharePoint list with the auto increment ID starting at 81 as it is in the table initially.
I understand Albert's logic, but somewhat disagree. I worked with one client that had been using an original Auto-numbered field as the Customer's ID in their access database for years, so their work orders, invoices, etc..., all have the Customer's ID there. If you use the newly-created autonumber field, then all customer id's would change to new numbers. Worse yet, if you use a 2nd, non-autonumber field as Albert recommends, then anytime you add a new customer, you would need to use a sql statement (or query) to determine the last used number from this 2nd field and increment it 1 so that it is unique. Kind of a pain.
So, the workaround is still a pain, but for a solution that does what you actually asked, you can do this. Create a new list in SharePoint with an auto-numbered field. link that list in the access database. then, look at the highest ID number (eg highest customer id) from the table with your original data... because you need to create that many rows in the SharePoint list. You can either create code to loop through creating x number of records, or if you're not comfortable with that, create an excel sheet with that many rows. then, import that excel file into the linked table. next, create a delete query which deletes all records in the linked table that doesn't have the matching ID (eg customer ID) in your access table. this leaves you with a linked list with only the IDs you are using, and it's still auto-numbering so new records are automatically assigned new numbers.
Like I said, it's a bit of a work-around. But this actually does what you are asking for, instead of being forced into a different solution.
If the column in question is a autonumber column, then during a upload or migration then those autonumbers can change. Since such numbers have NO meaning, then this should not matter. If you have several related tables then you MUST ensure that your relations are setup correctly before you move the data to sharepoint (because SharePooint will re-number these values, then the child tables and FK keys ALSO will be correctly updated). However, if you don't set the relationships, then you WILL break the related data since SharePoint does and can and will re-number the PK's used.
You are limited to ONLY using autonumber PK's if you wish to keep related tables intact. You cannot control this re-numbering, but as noted the number ONE rule in databases is that such numbers do NOT matter anyway.
If you MUST and WANT to stop the re-numbering of that column, then change the data type to a long number, and NOT autonumber type. And then of course simply add another autonumber column. So to STOP or PREVENT the numbers being changed, you have to convert the column from being autonumber to a standard long number column. (edit: you ALSO thus have to ensure that the column is NOT marked as PK).
Keep in mind that any other table as part of the related data will ALSO see those standard long number columns re-numbered and changed if that column is part of a defined relationships to some PK. So Access during a up-size WILL re-number the PK (autonumber) and will ALSO automatic for you re-number the FK columns used in child tables. If you as noted do NOT want such re-numbering to occur, then the PK and FK columns can NOT be part of a defined relationship.
So dropping the autonumber column is the only way to prevent such re-numbering. Since autonumbers don't have any real meaning, then if they are changed during a up-load, then this should not matter.
I'm creating a database that will be used to keep track of maintenance performed on equipment in a nursing home. I'm using MS Access 2010, and I'd say my skills are somewhere between novice and intermediate, almost entirely self-taught for this project.
The database structure is as follows:
tblAssetTypes:
TypeID (PK),
MaintenanceSchedule,
EquipmentType,
EquipmentSubgroup,
MaintenanceTime,
TasksRequired
tblUniqueAssets:
UniqueID (PK),
StorageLocation,
TypeID (FK)
tblPrevMaintRecord:
ID (PK),
UniqueID (FK),
DatePerformed,
TimePerformed,
MaintenanceComments
The UniqueID will be an identifier created by maintenance people, usually as four letters and then three numbers. I'm currently using "test001", "test002", etc.
I have a form that allows users to enter the UniqueID that has been assigned to an asset, select what kind of equipment it is, and where it is stored.
I'm currently creating another form which I want users to be able to select from a list of pre-existing UniqueIDs and then change the location that is stored in the table. However, as it is currently set up, every time I select a UniqueID from the combobox on the form, I get the following error. This error comes up after I have selected an UniqueID, and then if I try to do anything further, such as saving the record or even trying to close the form.
The changes you requested to the table were not successful because
they would create duplicate values in the index, primary key, or
relationship. Change the data in the field or fields that contain
duplicate data, remove the index, or redefine the index to permit
duplicate entries and try again.
I'm sure I probably need to give more information but I'm not sure what will be needed so I'll edit as needed.
How can I update the location information stored in tblUniqueAssets for a UniqueID value that already exists? Surely I wouldn't need to delete the record first and then create a new one with the previous UniqueID?
So I had an issue/problem that is detailed here (Sorting error in one field of Report), which leads to my current problem.
I have two tables (Owners and Boats) that were once joined in a relationship via the fields Boat_Owner – (number field on Boat Table) and Owner_ID - (Primary Key autonumber on Owner Table). Due to a problem the data type in the number field on Boat Table has been changed from number to short text.
So now the relationship is no longer working and as a result I’m getting the ‘data type mismatch’ error.
Both tables are intact with table Boat having 355 unique entries and table Owner having 295 unique entries, some owners own more than one boat. The autonumber ID’s are still intact in both tables so for example I know that Boat 401 finds its ownership with Owner 33. Unfortunately I cannot figure out how to re-establish the table relationships due to the aforementioned field data type issue.
I’m thinking I can run an append query to re-establish the owner_ID field into the Boat table as a number field.
From this point I’m going to manually enter all of the owner_ID. Far from desirable as there are 295 of them. I have been using excel to match the two tables on one spreadsheet but I’m open to suggestions if someone has a better procedure.
If it does work my thought is I could then re-establish the relationship between the two tables.
I’m not sure if I am going about this the best way, or even if this is the correct way to go about this.
If anyone has input I’m open to suggestions. I’ll post my progress if there is some.
Right now the column contains the names in text form.
Then you can do the following:
Create a new column in Boats: Owner_ID Number, Long integer.
Then fill this column with an UPDATE query from a join via the owner names:
UPDATE Boats INNER JOIN Owners
ON Boats.Boat_Owner = Owners.Owner_Name
SET Boats.Owner_ID = Owners.Owner_ID
If there are duplicate names (John Smith), there will be wrong assignments and you'll have to correct these manually.
When all Owner_ID's are assigned correctly, you can create a new 1:n relationship, now from Owners.Owner_ID to Boats.Owner_ID.
Afterwards you should delete the Boats.Boat_Owner column, it is now useless.
I've seen various posts here about not using lookup within a table. If you don't, how do you enforce referential integrity between a field and the allowable values from a lookup table? I can't create a relationship between the table field and the field in the lookup table because I can't create a unique (no duplicates) index on the field - the particular value needs to appear multiple times across the records in the table. But if I use the field properties to set a lookup on it and specify the field from the lookup table that it must contain, then this ensures that data can't be entered into this field that isn't in the lookup table.
Or have I got completely the wrong end of the stick here?
I recommend that you always create forms for editing records. And in those forms you can create combo boxes that perform the lookups in the correct table and field. There are options there so that you can limit the data entry to only those values which are stored in the table. This option is called Limit To List (you'll see it in the combo properties).
Another important way to enforce that data exists in your lookup table is through your Relationships.
tblProducts
ProductID (primary key)
CategoryID (foreign key)
ProductDescription
tblCategories
CategoryID (primary key)
Category
In the relationships window you would define a relationship between the two tables above on the CategoryID field. You are accomplishing several things here. It's more efficient to store only the CategoryID in your Products Table since you will be storing less data. Also, this way if you change the name on the category all records will reflect that change immediately. Every place that you display a product with its category you will need to create a combo box so that you display the Category Description as opposed to displaying the CategoryID.
As a side note, I recommend that you rarely use the Value List option as the Row Source Type in a combo. Using the Table/Query option and then creating an appropriate lookup table is a much more robust and flexible design.