Re: SQR as a database migration tool?

[Al <starbuckk1@YAHOO.COM>]

The trick to this is to create the link in the database rather than in SQR.
Have the DBA establish a database link and view from the target database to
the source database.  From an SQR perspective then you are only connecting
to one database and the database engine is handling the connect to the source.

You may encounter a problem if the tables have long fields in them as long
fields are not handled well in this fashion.

Users of the source database should not need to be off, but target database
users that would be accessing the affected tables need to be off unless you
try changing lock modes but doing so will cause performance issues with
Informix (running out of lock and journal space, slow response, longer
running process) if you have large tables to migrate.

With the utility options, check your lock modes and journalling.  These are
areas where you can improve Informix performance.  Journalling might not be
needed while you are doing the batch copies and making sure your lock modes
are not set to row level so you are not using a significant number of locks
during the process could improve the performance considerably.

At 12:01 AM 12/22/2001 -0700, you wrote:
>         I sent this once but it never showed up so I'm sending it again,
>slightly changed.
>
>         Basically, we need to copy client Informix databases. Current
>utility options to do this can take upwards of several hours and/or require
>clients to be off the database. Most of our clients are pharmacies, some 24
>hours, and so the lockout is unacceptable.
>
> > I assume that SQR can be used to migrate the info from one database to
> > another. Is this correct?
> > More importantly, what kind of lock would have to occur for this to
> > happen? Would users of the database have to get off before the migration
> > can take place?
> >
>         In short:
>         Can SQR maintain a connection to 2 databases at the same time?
>         Will the database need to be locked for a secure migration of data?
>
>
> > Thanks a tonne for any help,
> > B
> > The Programmer formerly known as Bob
> > Mediware Information Systems Inc.
> > (913) 307-1045
> > Bob.Helm@Mediware.com