[AccessD] Is anyone migrating data?

> In the end I will have a little program that pulls each record and applies
> the queries in the order they are in the table, such that the process is
> "push button" (with luck) and the client can do it themselves.
John,

I did do it like that - table driven data import and transformation - many
times - one example:

- importing data into MS Access 2.0/97 database from text files exported
from mainframe. The source data were rather "dirty". The whole process of
import worked sometimes more than an hour - there were around 300+ data
transformation queries, quite some tricky code, sometimes hundreds of
thousands source rows to import of AFAIKR 50+ or more source record types
etc.

It worked OK, without any problems on MS Access 97.
So I guess for you if you use MS Access XP or 2003 it should work even
better and quicker.

Do you expect any tough tasks to solve or ...?

Shamil

----- Original Message ----- 
From: "John Colby" <jwcolby at ColbyConsulting.com>
To: "'Access Developers discussion and problem solving'"
<accessd at databaseadvisors.com>
Sent: Friday, October 28, 2005 7:54 AM
Subject: [AccessD] Is anyone migrating data?


> I am right in the middle of a data migration job.  I am building a simple
> two table (so far) tool to assist me in organizing the data migration.
This
> will be a recurring migration, fairly complex.  The client hired people to
> build the system and get the data migrated once but that developer did not
> document the process, nor save the queries etc.  Thus I am having to learn
> the whole process from scratch using the "sit with the client and ask
> questions" method.  They want it documented this time naturally.
>
> I have migrated many different databases over the years but mostly the
> migrations were "one-shot" migrations designed to get the data from
> denormalized tables in to a new system I was building to replace the old
> system.  In this case, the old system will stay (mostly) with the same
data
> having to be imported every month, or quarter - something like that.
>
> The tool is pretty simple, just a form to list the table names, in the
order
> the tables need to be migrated, and some attributes to describe what that
> step is doing, then a child table to hold the query / SQL statement / code
> to run to migrate the data into that table.  Anyone who has done this
stuff
> knows that the process is usually order sensitive in terms of which tables
> get migrated when, and also the order that the queries are run for any
given
> table.  My objective is just to document the table / order / requirement /
> data source, plus the queries / order used for each table, with comments.
> In the end I will have a little program that pulls each record and applies
> the queries in the order they are in the table, such that the process is
> "push button" (with luck) and the client can do it themselves.
> Documentation will be in the comments in the table and can be pulled into
a
> report.
>
> If anyone else is doing this kind of stuff and wishes to collaborate with
> me, contact me offline.
>
> John W. Colby
> www.ColbyConsulting.com
>
> Contribute your unused CPU cycles to a good cause:
> http://folding.stanford.edu/
>
>
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com