Hello SQL people!
I am importing a group of customers in and have run into an issue. After setting up my C tables with all the contact info/attributes I wanted to import in with the customers, I ran the import script exec cp_constituent_import_session. It failed because of a duplicate Attribute value (which I thought I was checking for, but maybe missed). However, even if I find the culprit Attribute value, my C_PRIMARY_CUSTOMER table now has a session # for the constituents that failed to import. Is there a way for me to run the import script again for that same group, or do I need to add them back in to each C table with a blank session # in order to run exec cp_constituent_import_session again?
Thank you!!
Lily
Hi Lily. Normally I'm importing folks using the Constituent Import report/utility in the Client and running it in review mode till I get it right. When I have kooky data fields I create a new XML template to map them in.
Hi Lily!
Normally, I'd agree with Heath, but I'm assuming you want to bring in more data (phones, addresses, emails etc.) than the standard constituent import would allow. If that's the situation you're in, then yes, there is a way to clean up mistakes like this so you don't have to reload the data.
You'll want to verify which session ID was the problem, and how many constituent rows there are in the table for that session ID. Then execute the following:
begin transaction
update C_PRIMARY_CUSTOMER
set session, error_column,message,success_ind = null
where session = [your session id]
The WHERE statement is critical here- it limits the cleanup to only the rows in the table that match your failed import session. If this is not included it will reset the logging fields for ALL sessions in C_PRIMARY_CUSTOMER, so if there are previous imports in that table, your next run will try to import those again.
If the results of this query match the number of constituent rows you wanted to import, then execute
commit transaction
which permanently writes those changes to the table.
If they don't, execute
rollback transaction
which undoes the changes without permanently altering anything.
I would also recommend checking any other import tables you'd populated and verifying whether the errors from C_PRIMARY_CUSTOMER cascaded into those. If that's the case, you'll want to run the same cleanup script on those tables as well.
Thank you both so much! Jonathan, that did the trick! My constituent import is complete! Ended up just inserting the problem Attributes directly from my Temp file into TX_CUST_KEYWORD once the C_PRIMARY_CUSTOMER and contact tables were imported successfully. It was the C_ATTRIBUTES table that was unhappy.
Thanks again!