I am developing an application for use within my department at work. The application needs to access a list of people that is supplied by my company.
This is kind of a mess, though, as my company does not maintain very clean data and that situation cannot be changed. I will use sample table names and such here for brevity.
Here is the current workflow for how I get this data into my database:
I receive a monthly report, in Excel (XLSX) format from my company.
Convert the report to CSV.
Delete all items from the current [people] table
Import the CSV data into the [people] table
I can not change this process to simple UPDATE or INSERT statements due to several factors:
There is a lot of duplicate data in the reports I receive
Each person can be listed in the report multiple times, with slight variations in the data in each column (ie: they may have several entries for each person but with different addresses for each row).
My company uses two "IDs" to identify the person, but they recycle these IDs. If a person is deleted from their records, for example, they may take that person's ID and assign it to a new person.
Without making the entire row the PK, is there any way to salvage this situation to create a true table that can be accurately referenced from another?
Related
If a table has multiple sources (each source contains a different type of data), is it best practice to split that table into multiple tabes (with the necessary foreign keys) or do you nevertheless fit it into one table.
simplified example:
want to make a table containing client info
2 sources of data, all csv files:
static data, almost never changes (e.g. start of the relationship, headquarters, etc)
revenue data which changes monthly
In this case do you go for one table (e.g. t_client) containing both static and revenue data, which you then update monthly? Or do you make multiple tables: one with the static data (e.g. t_client_info) and one with the variable info (t_client_revenue, update monthly) and link them?
just want to know what is best practice
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?
I am setting up a database using MySQL with the goal of storing data for a potentially large number of unique users. Each user will have some basic data associated with them - a unique username, when they joined the service, how many times they have used the service, in addition to a set of their personal preferences. I am planning on keeping one table called 'Users' dedicated to these fields.
However, there is a bunch of data with a specific schema that will be collected about that user during each session that they use the service. This data includes which user performed this session, the date of the session, what the user did, etc.
My thought process is the following: if I use a single table for users that includes data on each of their sessions, this seems inefficient because there would have to be either a column for each unique session, or a column containing more or less an array or list of sessions. If I wanted to keep this data for an indeterminate number of sessions, then the one-per-column idea would break down, because I believe there is a column limit. Updating an array within a single column also seems to be frowned upon, I think for reasons having to do with preserving the integrity of the data and maintaining the best possible organization.
So it seems like I want two tables, one for users, and another for sessions. Every time anybody completes a session, data about that session will be created as a new row in the 'Sessions' table, and each row would also have a foreign key linking that session to the particular user who completed it.
Is this a correct line of thought? If not, how should I think about this?
Thanks
I would say you're pretty close. You should separate users and sessions, and you're looking at modeling a relationship. Each session only has one user, so it's a one-to-many relationship.
1 User (1 Row in the "Users" table) can have many Sessions (1 Row in the "Sessions" table)
The Foreign Key is the User ID in the Sessions table. This links each unique session (Which will have it's own Session ID I'm assuming) back to a unique User in the Users table.
If you're looking at a massive volume of users, which means a ton of sessions, you may want to consider options on how to help the sessions table not grow to be extremely huge and slow to query. If you're collecting this data on a daily basis, consider that you could "Partition" the table on dates:
Partitioning on DateTime in MySQL
edit: typos
I am creating a web application for internal use. One of the main features is the ability for the users to enter Sales Call Reports. My question is simply: Do I store the Employee Name and Company Name in the Call Reports table or do I only store the employee number and customer number in the table, as foreign keys and then retrieve the Employee Name and Customer Name, using the foreign keys, for display purposes? It seems like the foreign keys option would be procedural correct, however, it would be much easier to retrieve data from only 1 table when displaying the call reports.
Usually you'll save future-you a lot of pain by storing them separately as you've described.
On the face of it, and initially it seems like lots of extra work, but you'll end up with a much more flexible system, and 2 JOINS in a query isn't a lot.