We are a group of users of Blackbaud products and are not affiliated with Blackbaud. We'd love to have you join our community to help and be helped in getting the most from your Blackbaud software.
Register now to join us to get independant advice on your system, connect with 3rd party consultants to help you maximize your database and have a real alternative to the official Blackbaud website.
I could certainly use some help trying to figure out why when I create a constituent phone import off of a stand-alone version of RE and I then try to import the file into my live database I get exceptions of
"record does not exist"
The only thing I do to the record before entering is I add a 3-letter code to the end of the import fields since we have numerous databases in our live version so to make the ID's unique and that is carried throughout.
Anyone know what I might be doing wrong?
I double checked my field mapping and those appear to be correct.
My guess, without looking at the file, is that your address import IDs don't correspond to existing addresses. You said you were modifying the import IDs, but not whether it was the address, the phone, or both. In either case, I would not expect the address import IDs in your test environment to match the ones in your production environment, particularly since you are altering the structure of the import IDs by adding three characters to the end. Why are you even using the test database to create the files in the first place?
Drew
__________________ J. Drew Allen
Children's Hospital of Philadelphia
Crystal Reports and SQL Server Consultant
It is better to live your destiny imperfectly than to live an imitation of somebody else's life with perfection.
We house about 30 databases for different chapters within our organization. The new chapter I am bringing in previously used RE.
So we have their original database on the standalone version that they sent to us and then bring it into the giant database with the other 30 chapters.
Does that make sense. We give the chapters the ability to connect to the database via remote desktop connection and have their security rights to only view their constituents.
The import ID field is limited to 20 characters. If you add three characters to a 20-character import ID, the last three characters will get truncated. I'm not sure when this truncation happens, so when you import the phones, it may be trying to compare the 23-character field from the file to the 20-character field in the database and, naturally, not find a match.
Drew
__________________ J. Drew Allen
Children's Hospital of Philadelphia
Crystal Reports and SQL Server Consultant
It is better to live your destiny imperfectly than to live an imitation of somebody else's life with perfection.
We house about 30 databases for different chapters within our organization. The new chapter I am bringing in previously used RE.
So we have their original database on the standalone version that they sent to us and then bring it into the giant database with the other 30 chapters.
Does that make sense. We give the chapters the ability to connect to the database via remote desktop connection and have their security rights to only view their constituents.
Do these phone numbers already exist in your giant database? Unless they are already in there they can't be imported with just these fields. It is looking for these phone import IDs to already be in there. (you would only do this if you were overwriting existing phone numbers in your database)
If they are being added to existing records you will need the Constituent Import ID (or Constituent ID) and Address Import ID of where you want the phone numbers to go.
The import filed name PhoneAddrImpID is using the Raiser's edge field of Address Import ID.
I am thinking that Drew may be on the right track with the number of character allowed in the field I am trying to add the 3-letter code to make it "unique" to the giant database.
Thank you everyone for all your help!! I am new to the world of importing and struggling to stay afloat as I learn.
Unless you really need to specify the import id's for some reason, I would just let the system create them... I used to create all of mine, and it got to be such a hassle since BB doesn't use unique identifiers as their import IDs that I finally just let it do it...
Just another thing to make your life a little easier. (Note: I'm talking about not specifying the phone import IDs, the address ones will have to be specified in order to link the phones to the address).
Doug
__________________ ~~~~~~~~~~~~~~~~~~~
Doug Creek
RE Database Administrator
University of Alaska Foundation sndgc@email.alaska.edu
I am thinking that Drew may be on the right track with the number of character allowed in the field I am trying to add the 3-letter code to make it "unique" to the giant database.
If the import IDs on the standalone were auto-generated, there is another approach that you can use if you know the structure of the auto-generated numbers.
The auto numbers have three sections. The first section is based on the serial number of your database, although there is a problem with some serial numbers (maybe enterprise edition). If this first set of numbers in your main database and your standalone are different, then you don't need to do anything for auto numbers, but you will for non-auto numbers.
Where you might run into a problem is if the serial numbers in each database don't meet the pattern that the function is trying to match. In that case, both databases will have auto-numbers beginning with "00001-". In that case, you can simply replace the "00001-" in your import files with your three digit code. This requires that the addresses be imported with this same change, however. If you've already imported the addresses, you'll probably have to delete them and start over.
Drew
__________________ J. Drew Allen
Children's Hospital of Philadelphia
Crystal Reports and SQL Server Consultant
It is better to live your destiny imperfectly than to live an imitation of somebody else's life with perfection.