Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Changing the Past


Changing the Past

Author
Message
Steve Jones
Steve Jones
SSC-Dedicated
SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)

Group: Administrators
Points: 36083 Visits: 18738
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
My Blog: www.voiceofthedba.com
call.copse
call.copse
SSCrazy
SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)

Group: General Forum Members
Points: 2843 Visits: 1857
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.
Thomas Foster-Baker
Thomas Foster-Baker
Old Hand
Old Hand (372 reputation)Old Hand (372 reputation)Old Hand (372 reputation)Old Hand (372 reputation)Old Hand (372 reputation)Old Hand (372 reputation)Old Hand (372 reputation)Old Hand (372 reputation)

Group: General Forum Members
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.
IMHO
IMHO
Old Hand
Old Hand (305 reputation)Old Hand (305 reputation)Old Hand (305 reputation)Old Hand (305 reputation)Old Hand (305 reputation)Old Hand (305 reputation)Old Hand (305 reputation)Old Hand (305 reputation)

Group: General Forum Members
Points: 305 Visits: 276
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.
jeffgonnering
jeffgonnering
SSC Veteran
SSC Veteran (297 reputation)SSC Veteran (297 reputation)SSC Veteran (297 reputation)SSC Veteran (297 reputation)SSC Veteran (297 reputation)SSC Veteran (297 reputation)SSC Veteran (297 reputation)SSC Veteran (297 reputation)

Group: General Forum Members
Points: 297 Visits: 518
For all of you that have perfect data entry personnel, or don't have to deal with 3rd shift temp workers :-), 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.
bwillsie-842793
bwillsie-842793
SSC-Enthusiastic
SSC-Enthusiastic (111 reputation)SSC-Enthusiastic (111 reputation)SSC-Enthusiastic (111 reputation)SSC-Enthusiastic (111 reputation)SSC-Enthusiastic (111 reputation)SSC-Enthusiastic (111 reputation)SSC-Enthusiastic (111 reputation)SSC-Enthusiastic (111 reputation)

Group: General Forum Members
Points: 111 Visits: 290
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.
cesullivan
cesullivan
Forum Newbie
Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)

Group: General Forum Members
Points: 4 Visits: 8
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.
SQLRNNR
SQLRNNR
SSC-Insane
SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)

Group: General Forum Members
Points: 21075 Visits: 18259
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, MVP


SQL RNNR

Posting Performance Based Questions - Gail Shaw

krowley
krowley
SSC-Enthusiastic
SSC-Enthusiastic (132 reputation)SSC-Enthusiastic (132 reputation)SSC-Enthusiastic (132 reputation)SSC-Enthusiastic (132 reputation)SSC-Enthusiastic (132 reputation)SSC-Enthusiastic (132 reputation)SSC-Enthusiastic (132 reputation)SSC-Enthusiastic (132 reputation)

Group: General Forum Members
Points: 132 Visits: 429
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.
webrunner
webrunner
Hall of Fame
Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)

Group: General Forum Members
Points: 3028 Visits: 3752
Thomas Foster-Baker (1/21/2011)
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.


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

-------------------
"I love spending twice as long and working twice as hard to get half as much done!" – Nobody ever.
Ref.: http://www.adminarsenal.com/admin-arsenal-blog/powershell-how-to-write-your-first-powershell-script

"Operator! Give me the number for 911!" - Homer Simpson

"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
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search