How to globally add "start date" to already exisiting const codes

Beth Gibney

Hi everyone!  Happy Holidays!


I have approximately 7,000 records with a particular constituent code.  I need to globally add the same start date to all of them.  I couldn't figure out a way to do this via global add.  I've never done an import before so is there a way to do this without importing?  Am I missing it in the global add/change area?


Any input is appreciated!


Thank you,


Beth

Claudia Sauers

It is a global change, if you condense all of your options in the left hand side, there is an area for constituent codes, and you can "add" a date from

JoAnn Strommen

Be sure to test first on one or two records. Constituent code date from could be one ot those fields that will change on every constituent code on the record. If that's what you want fine, but if you just want the date added to one particular code it may not be.  I don't have ability to test at this moment. Take a screen shot of one record with more than one code, do the global change and see what happens. (I wanted to put a date in once on one assigned solicitor and it changed all solicitors on record.)  You may have to do an import. Exporting out the data you need to change and then bringing it back in is definitely easier than some import types.

Steven Cinquegrana 2

I agree with JoAnn 1000%.


This kind of scenario presents a good argument for having a test database set up, or running your change against the sample database. Or performing the change after hours and after a back-up has been taken. Five minutes of testing can save literally hours of recovery work if the global change turns out to be not to spec.


Cheers,

Steve Cinquegrana | CEO and Principal Developer | Protégé Solutions

 

Jen Claudy

This sort of testing is why I like to keep a set of dummy records in my production database.  I can set up any scenario I want, test any process, and then don't have to worry about setting anything back to rights.  I used ConstID 4567890, 4567891, 4567892, & 4567893...married couple both with records, married couple on just one record, org record.  All had a ConstCode & ConstNote to mark as Dummy records and exclude them from any reports or mailings (which could also be done with a prefix on the ConstID).


The most important thing is to test with just one or two records.  I personally dislike testing in a Sample Database, because then I have to set up the GC or whatever I'm doing over again in the production db...not to mention, the sample db doesn't have all of my records and appeals in it, so it doesn't always have the same results. 

Simon Stacey

Jen Claudy:

The most important thing is to test with just one or two records.  I personally dislike testing in a Sample Database, because then I have to set up the GC or whatever I'm doing over again in the production db...not to mention, the sample db doesn't have all of my records and appeals in it, so it doesn't always have the same results. 

We regularly use a backup copy of our 'Live' database to refresh our 'Test' database, which ensures that it's a useful copy of the Live database. Handy for testing any GCs that would be hideously destructive should they go wrong on the Live system.

Alan French

JoAnn Strommen:

Constituent code date from could be one ot those fields that will change on every constituent code on the record.

I've not tested it but I suspect JoAnn's right on this one. As they're all the same codes and dates, it may well be quicker to just use global change to delete the original codes entirely and then use global add to put them back on including the date.

Beth Gibney

alan, great idea.  Thank you.  If I run the query of the const code, then global delete that code off of the records, will i lose my data in my query since the query was based off of the code that i just removed?  How do I retain a query of those records to then add back in the code with the start date?

JoAnn Strommen

Very good point.


What I've done for similar situation is create new with different or slightly different name first. Yes, then after, delete the original. Just did with one of our primary use attributes where we needed it connected to a different table.

Aaron Rothberg

You could create a query based on Constituent Code, export the Constituent Ids, then import the Constituent Ids back into Raiser's Edge to build a static query based on ConsId (or you could avoid Import by copy-pasting the Constituent Ids into a new query). That way your query will retain the same constituents even after deleting the Constituent Code.

Andrew Ludwell

Aaron Rothberg:

You could create a query based on Constituent Code, export the Constituent Ids, then import the Constituent Ids back into Raiser's Edge to build a static query based on ConsId (or you could avoid Import by copy-pasting the Constituent Ids into a new query). That way your query will retain the same constituents even after deleting the Constituent Code.

If you create the query and then either save it as a static query or as a query list, this will retain the original list of constituents without having to export and import. (NB: if you choose the static query option, don't change the parameters after you make the change as that will refresh the output and lose the original list.)