Re: Year 2000 testing - aging Oracle data

Steve
Aging data in any system can be a complex task at best, especially if you want to make sure that the dates you end up with make logical sense to you programs. Just adding a standard number of years, months, days etc to the date values may not do this.

For example, if you add 4 years to the date 01/04/1998, which is a Wednesday, the date you would end up with would be a valid date, but on a Saturday. Now your programs may only be expecting dates that lie within Monday to Friday, and as a result, the program either fails, or produces rubbish results. What you need to be able to do is apply business rules to the aged data so that the data is flexed so as to make the date fall on the next working day, or the previous one, or whatever criteria make sense to you.

There is a product, available imminently form Princeton Softech, called MOVE FOR SERVERS - ORACLE, which will allow you to do this. It is a relational data extract and insertion tool, which as one of it's functions, allows you to age data in columns defined as dates to the tool, and apply business rules to those aged dates, prior to inserting that data to a target database - a process we call semantic aging.

The tool can extract relationaly intact sub-sets of data, as well as schemas (table definitions views indexes etc) of the source objects, store that information in a file, and then insert that info into a target database, after optionally first creating the target tables etc. The data can be modified at insertion time, and it is here that the semantic aging is performed.

If you wish to know more, you can connect to Princeton Softech's web page at www.princetonsoftech.com

I hope this helps.         

In article <01bdbf65$f6cbdec0$0d050506_at_m0n7y>, Stephen Boyle <boylesa_at_dial.pipex.com> writes

>Steve
>
>I would be tempted to use Access(or something similar) to roll-forward all
>of the data.
>
>If you connect to all of the tables i think you can then walk through the
>system tables using the Access dao. This data could be used to
>programmatically create a table showing table name, field names (of all
>date type fields), and some mask showing the relationships which must be
>upheld i.e only weekdays etc (when masking out days consider using bitwise
>manipulation).
>
>A second piece of code could then be used to walk this table and create SQL
>queries (passthrough if req'd) to update the associated Oracle tables.
>
>Hope this helps
>
>Steve
>
>
>SJPBooth <sjpbooth_at_aol.com> wrote in article
><1998073012411500.IAA07360_at_ladder03.news.aol.com>...
>> Hi,
>>
>> As part of the testing plan for Year 2000 work, it's necessary to age
>dates in
>> the Orcale databases so that they reflect dates in 1999, 2000, etc. It's
>> important that the dates retain their interrelationships and that they
>conform
>> to rules like not falling on a weekend or holiday.
>>
>> Anybody else hit this? Any ideas?
>>
>> Thanks,
>> Steve
>>

Best regards
--
  Alan Johns
  Tarragon Software Ltd - UK & Ireland Distributor for

        Princeton Softech's -   Upgrade 2000
                                Ager 2000
                                Relational Tools for DB2
                                Version Merger
        

Phone: 44(0)1487 815815
  Fax: 44(0)1487 812282 Received on Wed Aug 05 1998 - 05:35:08 CDT