• Budget ? Seriously? Somebody must not be thinking. Whatever application is populating the database needs what is likely a 5 second change and then either a redeploy or a recompile and redeploy, and if the whole process were to take more than an hour, I'd be floored. Even a regression test shouldn't take all that long, and having to move something through DEV. TEST, QA, UAT, and PRODUCTION might take a tad longer, but still... this is a seriously simple fix to any query that populates a datetime field.

    Alternatively (and now that I think about it), you might be able to add a trigger and do an insert into a new table that would tie the primary key from the original table to a datetime field whose DEFAULT value is GETDATE(). That way, the TRIGGER only has to insert the primary key from the other table, and it keeps the overall cost of the trigger on iinserts and updates fairly small. You'd also have to trigger on DELETE to remove the appropriate records from the new table as well. In the overall scheme of things, might be an easy fix. It doesn't do much for the existing records, but if the volume of those is small, have somebody decide what the status is for each one affected, and manually update this new table to reflect the decisions made.

    Your thoughts?

    Steve (aka sgmunson) 🙂 🙂 🙂
    Rent Servers for Income (picks and shovels strategy)