Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Changing the Past Expand / Collapse
Author
Message
Posted Thursday, January 20, 2011 9:30 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 4:38 PM
Points: 31,018, Visits: 15,453
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
Posted Friday, January 21, 2011 2:25 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 3:41 AM
Points: 1,699, Visits: 1,116
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
Posted Friday, January 21, 2011 2:34 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld 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
Posted Friday, January 21, 2011 7:30 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Friday, August 1, 2014 9:06 AM
Points: 252, Visits: 194
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
Posted Friday, January 21, 2011 8:13 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, September 2, 2014 2:23 PM
Points: 193, Visits: 340
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.
Post #1051574
Posted Friday, January 21, 2011 8:39 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, July 17, 2013 12:22 PM
Points: 107, 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.
Post #1051595
Posted Friday, January 21, 2011 10:31 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum 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
Posted Friday, January 21, 2011 12:49 PM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Today @ 5:20 PM
Points: 17,600, Visits: 15,462
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


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
Posted Friday, January 21, 2011 3:45 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, August 28, 2014 1:35 PM
Points: 113, Visits: 423
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
Posted Monday, January 24, 2011 9:32 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 8:20 AM
Points: 2,373, Visits: 2,726
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


-------------------
"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
Post #1052484
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse