If I was to create a CRM D'base, or just a nice Contact D'base, what would happen if I tried to import data from 2 different spreadsheets that may have some dups in it? Be nice please. I've hardly EVER worked with Access, so I scant hardly know what I'm doing.
Thanks,
GPLea
You can have duplicates in a database as long as the particular field where the duplicate appears is not designated as unique. For instance, you might have a field named CustomerId which would be designated as a unique field because you want to be able to uniquely identify that customer but the CompanyName field would not be set to unique because you could have more than 1 Company named Acme.
If you were to import records from different sources, you could have duplicates so you would want to clean out the duplicates before setting any fields to unique. If there are duplicates in the field you attempt to set as unique, it won't work until you clean up all duplicates.
Last edited by strollin; 29 Sep 2014 at 22:05.
Access is a very good Database, but it does take some getting accustomed to it & the way it works.
I always think the most important thing is to get your Tables set up exactly how you want them. This often takes trial & error, so you may have to start again a few times to get it right, but don't get put off.
Don't delete your spreadsheets until you get Access set up the way you want it as you may decide to redo it & still want to have the original data available.
Are the spreadsheets you will be using Excel, or another spreadsheet. Have a look at what you have in the spreadsheets for layout & apply that order & layout for your Table in Access, if that is how you would like it.
As strollin has suggested it would be best to remove any duplicates from your spreadsheets.
You may find this MS website helpful in getting to know Access. Scroll right down & you will see a section "That's not All" that has a link for demo videos on Access.
Access 2007 training courses - Training
Thanks Guys. I WILL visit that site. So, to specify my question a little more. I saw where it asks me what I want to do with dups. My question is if I do have dupes, what does it do with them if I say NOT to accept dupes. 2.) I know I'm going to have to do some subsequent imports for additional records, and since it's not a cloud-based app, I can't share the d'base, so how would you suggest that I proceed with that process? My initial thought is to take input the records on the spreadsheet according to alphabetical order, and only input from say A-F, then, G-L, and so forth. That way there's should be no chance of dupes, and at least we can check the spreadsheet much more easily for dupes. To that end, if I make the spreadsheets as alphabetically described, should they be complete separate files, or if they're the same file, just different sheets, will Access prompt me for the correct sheet I want to import?
Finally, here's a tougher question. So, my 1st Primary Keys are names of churches. Now, many of these churches have multiple campi (campuses) that operate under their authority. So, I don't have a CLUE as to how to set that up as a parent/child relationship for the single user that will actually be using the d'base.
Thanks,
GPLea
If you specify NOT to accept dups then it will skip over duplicates, leaving them in the original file.
I don't understand your thinking with importing A-F then G-L as that should have no effect on duplicates. Wouldn't a duplicate sort alphabetically so that the duplicates show as subsequent rows?
As far as churches with multiple campuses, you will need to have an additional field to name the campus so a record would include both the church name and it's campus. DB design can get quite complex, there are many ways to do it including using multiple tables. If you design queries and reports correctly, the user of the db application will not need to understand the parent/child relationship of the church to it's campuses. The user should only need to run the report or query you provide to be able to get the info needed.
You need to design a db app for the level of expertise of the user. If they are knowledgeable, then they can write their own queries, otherwise they depend on what is provided to them.
Thanks again, Strollin. My objective/concern with the separate sheets is if I don't separate them alphabetically, then when I import say G-L, but I still have the A-F data in that spreadsheet then there will surely be dupes. If I separate the data into separate sheets, I'm assured that won't happen. Correct?
As for the multiple campi issue, this sounds like a silly question I guess, but how would I Google that issue, or look it up in the Help file?
Thanks Again,
GPLea
Maybe start here: Design tables for a new Access 2007 database - Training
(Sorry - Just noticed this link is included in the link provided by Ranger4 above)
Quote