Changing the Past

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQLServerCentral.com » Editorials » Changing the Past

12 posts, Page 1 of 2

1 2 »»

Changing the Past

Rate Topic

Display Mode

Topic Options

Author

Message

Steve Jones - SSC Editor

Posted Thursday, January 20, 2011 9:30 PM

SSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 2:54 PM
Points: 31,410, Visits: 13,726

Comments posted to this topic are about the item Changing the Past

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help

Post #1051310

call.copse

Posted Friday, January 21, 2011 2:25 AM

Ten Centuries

Group: General Forum Members
Last Login: Yesterday @ 4:58 AM
Points: 1,083, Visits: 689

I can't really think of any time appropriate to alter past data apart from when an error has been picked up that did not affect the situation in a major way - currently I am zeroing some starting account balance figures generated automatically by data uploaded before it should have been (a couple of months ago). It was not seen, because the balance was not noted, due to the fact that it should not have even been there - no-one looks for something they do not expect.

In general any 'used' data needs to be corrected rather than amended.

Post #1051388

Thomas Foster-Baker

Posted Friday, January 21, 2011 2:34 AM

Old Hand

Group: General Forum Members
Last Login: Monday, October 29, 2012 4:10 AM
Points: 372, Visits: 55

should we consider using transactions tables in our databases so any errors can be amended with adjustments to transactions so all corrections can be followed as we do in account programs.
This would please the auditors and give a clear picture of what has happened.

Post #1051391

IMHO

Posted Friday, January 21, 2011 7:30 AM

SSC Veteran

Group: General Forum Members
Last Login: Wednesday, May 08, 2013 11:45 AM
Points: 212, Visits: 140

IMHO the whole point of collecting data is to know the truth about something. If you are changing archives to mislead someone then, unless your motive is to directly save people's lives, it's no different than lying. But, if you're changing data because it misrepresents the truth in its archived form, then by all means. Say for instance, a CEO authorized the entry of false data into the database in order to make himself/herself look better. Years later, from his/her jail cell the CEO confesses that he added 10% to his/her market research numbers. I don't see any problem with going back and adjusting the data so that it would now accurately reflect what it was intended to reflect. You could always just delete the data, but, assuming you trust the jail cell confession, it's possible it could still be usable.

Post #1051522

jeffgonnering

Posted Friday, January 21, 2011 8:13 AM

SSC Journeyman

Group: General Forum Members
Last Login: Friday, May 17, 2013 2:44 PM
Points: 78, Visits: 235

For all of you that have perfect data entry personnel, or don't have to deal with 3rd shift temp workers Smile

, then changing bad data is nothing to worry about. For the rest of us, fixing incorrect data is a business necessity. As long as you follow separation of duties, audit the update with the who, when, where, why, and an auditor can see the before and after data, you would not be violating even the strictest compliance on earth. Not medical, defense, you name it.

Post #1051574

bwillsie-842793

Posted Friday, January 21, 2011 8:39 AM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, April 12, 2013 7:43 AM
Points: 107, Visits: 287

When would I change archived data? Never.

Would I add in offsetting transactions if appropriate, auditable, and agreed upon by higher powers? Yes. Without all three? Never.

Post #1051595

cesullivan

Posted Friday, January 21, 2011 10:31 AM

Forum Newbie

Group: General Forum Members
Last Login: Tuesday, January 25, 2011 11:13 AM
Points: 4, Visits: 4

A number of years ago, my employer used Social Security Numbers as employee ID numbers. These were embedded in payroll transactions that were part of budgets. When a new employee ID numbers were issued, the old payroll records had to be changed.

Post #1051692

SQLRNNR

Posted Friday, January 21, 2011 12:49 PM

SSCoach

Group: General Forum Members
Last Login: Yesterday @ 1:07 PM
Points: 18,733, Visits: 12,332

Even in the case presented in the editorial, the data was not changed - just amended. I'm not opposed to amending in a fashion where a new record is added and a query combines the records upon display. Please don't alter archive data though.

Jason AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server 2008

SQL RNNR

Posting Performance Based Questions - Gail Shaw
Posting Data Etiquette - Jeff Moden
Hidden RBAR - Jeff Moden
VLFs and the Tran Log - Kimberly Tripp

Post #1051773

krowley

Posted Friday, January 21, 2011 3:45 PM

SSC Journeyman

Group: General Forum Members
Last Login: Wednesday, May 15, 2013 9:16 AM
Points: 89, Visits: 341

Something not mentioned here is when court ordered to do so, for instance to completely remove any information about a particular client from your records because the court feels this is necessary.

Post #1051881

webrunner

Posted Monday, January 24, 2011 9:32 AM

SSCrazy

Group: General Forum Members
Last Login: Wednesday, May 15, 2013 3:05 PM
Points: 2,117, Visits: 2,209

Thomas Foster-Baker (1/21/2011)

I agree. This is a fascinating issue that I should learn more about, but it seems to me that as long as the chain of correction is audited and logged as well, then there would be no danger of being accused of covering up or lying. To follow Steve's example, if a tax error was found and corrected, then, in something analogous to a version control system, the original archived data would be preserved in a sense by showing what it was before, then what changes were needed to correct the error, and then what the post-change data was. That would also allow the system to track what "new" historical data leads up to the current state of the system. In some ways that is better because it won't leave people with questions about apparent inconsistencies in the data trail, which would likely come up if the archived data were "silently" corrected without any other logging of what happened to change it.

As far as I am concerned, the only reason changing historical data becomes suspect is when certain changes are left out to give the impression that the original data was different from the start, i.e., rewriting the past in Animal Farm fashion, otherwise known as fraud. As long as all changes to the data are tracked and associated with the people who changed it, and of course as long as the changes themselves are legal or necessary to bring the data in line with the law or with whatever the accepted business requirements are, then I don't see a problem with such presumably necessary modifications.

- webrunner

-------------------
"The chemistry must be respected." - Walter White

"A SQL query walks into a bar and sees two tables. He walks up to them and says 'Can I join you?'"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html

Post #1052484

« Prev Topic | Next Topic »

12 posts, Page 1 of 2

1 2 »»

Permissions