Thanks Maureen,
Being somewhat simple minded, can you give me a specific example of "each
of
which produces records that accumulate rapidly in that particular location
(on that server processed by that module of the software) which may be more
or less readable by non-system experts (e.g. by attorneys).".
I read what you are saying, but unsure as to an instance, application or
report. And honestly, I have not ever worked with huge mega systems of data
where this occurs. Or at least on the smaller applications, I am not
aware this is happening in the background.
Trudy M. Phillips
File Management, LLC
"Bringing Order Out of Chaos"
8440 Lanewood Circle
Leeds, AL 35094
Office: 205/699-8571 Fax: 205/699-3278
_www.filemanagement.com_ (http://www.filemanagement.com/)
In a message dated 8/6/2009 7:56:58 P.M. Central Daylight Time,
[log in to unmask] writes:
Well the distinction between raw data and final 'record' gets blurred with
big complex systems: there may be two dozen middle processing steps, each
of
which produces records that accumulate rapidly in that particular location
(on that server processed by that module of the software) which may be more
or less readable by non-system experts (e.g. by attorneys). These 'raw
data' middle-step processing records may specifically be required in law
suits when the issue is the way the system processed the data; so the data
in module 1 must be compared with the same data in module 2 and so on
through the data's journey to becoming a final record that, for example was
the basis of a company decision and/or that was mailed to a customer.
Maureen
On Thu, Aug 6, 2009 at 5:06 PM, Trudy M Phillips <[log in to unmask]>
wrote:
> Well, I am not understanding this conversation thread at all.
>
> I thought we had determined that data in a database or in a spreadsheet
was
> just data until a report was created from the data and such report was
> would be attached to the retention period for which the report was
> created?
> So, how can you parse sections of a database? To me, databases are in
a
> continual state of flux? Data changes, sometimes by the minute. I do
> not
> see a database as being stagnant so there for needing a retention period
> requirement.
>
> Now if it is a database, that was created for a specific purpose and not
> changed afterwards, then yes I can see that it could then become
something
> with a retention period.
>
> Trudy M. Phillips
> File Management, LLC
> "Bringing Order Out of Chaos"
> 8440 Lanewood Circle
> Leeds, AL 35094
> Office: 205/699-8571 Fax: 205/699-3278
> _www.filemanagement.com_ (http://www.filemanagement.com/)
>
>
> In a message dated 8/6/2009 5:19:38 P.M. Central Daylight Time,
> [log in to unmask] writes:
>
> I usually find out the preference of the users or IT administrator and
> it's
> usually one of three things: (1) to parse sections of the db and
establish
> particular retention periods for each, (2) to run static reports and
> consider those the (only) 'records, (3) to retain the whole database.
The
> last option entails locking the down the database at a certain point,
e.g.
> at the end of a project, and using the youngest record's creation or
> modified date to begin the retention period; this is similar to the
> concept
> of 'closing the record series' (a phrase repeated in the UK
government's
> ERMS requirements standard). The first option is surprisingly popular
with
> some IT people if the database is big, complex, with multiple IT support
> people, strict capacity limits, and if different business units use
> different sections of the system. The second option: it's difficult to
> reach
> consensus on what to capture in a report, and what is important will
> change
> over time anyway, plus there are risks to deleting the underlying data
> (you
> never know what will be needed in a law suit).
>
>
> --
> Maureen,
>
> List archives at http://lists.ufl.edu/archives/recmgmt-l.html
> Contact [log in to unmask] for assistance
> To unsubscribe from this list, click the below link. If not already
> present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of
the
> message.
> mailto:[log in to unmask]
>
>
>
>
> List archives at http://lists.ufl.edu/archives/recmgmt-l.html
> Contact [log in to unmask] for assistance
> To unsubscribe from this list, click the below link. If not already
> present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of
the
> message.
> mailto:[log in to unmask]
>
--
Maureen,
List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already
present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the
message.
mailto:[log in to unmask]
List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]
|