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

Options
Beth Gibney
Beth Gibney ✭
Tenth Anniversary Facilitator 1 Name Dropper Photogenic
in Blackbaud Raiser's Edge NXT®: General Discussion
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
Tagged:

Comments

  • Claudia Sauers
    Claudia Sauers ✭
    Seventh Anniversary Facilitator 2 Name Dropper Photogenic
    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
  • Steven Cinquegrana 2
    Steven Cinquegrana 2 ✭
    Ninth Anniversary Facilitator 3 Name Dropper Photogenic
    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
    Jen Claudy ✭
    Tenth Anniversary Facilitator 4 Name Dropper Photogenic
    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
    Simon Stacey ✭
    Seventh Anniversary Photogenic First Reply

    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
    Alan French ✭
    Tenth Anniversary Facilitator 3 Name Dropper Photogenic

    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
    Beth Gibney ✭
    Tenth Anniversary Facilitator 1 Name Dropper Photogenic
    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
    JoAnn Strommen ✭✭✭✭✭
    Ancient Membership Facilitator 4 Name Dropper Photogenic
    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
    Aaron Rothberg ✭
    Eighth Anniversary Facilitator 2 Name Dropper Photogenic
    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
    Andrew Ludwell ✭
    Eighth Anniversary Facilitator 1 Photogenic

    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.)

Categories