Major migrations take a bit of time to configure and tune. I know - I
am currently in the middle of a two phase migration of a major database
subsystem. A major migration and integration effort may take a year to
set up, configure, and test, then an hour to run, and finally another
year to get fully debugged.

1. Have you considered building a migration toolkit?

A migration toolkit that allows the consultant to map input table/column
to your application's table/column, run simple joins and
transformations, and then run the actual migration process as a single
automated batch can save a lot of time, money, and headaches.

The core of a generic automated batch migration process can be written
in about 3 days with the right tools, and it can save many times its
cost in manpower to resolve problems.

2. Have you considered providing a validation tool set?

Automated validation tools built using jUnit (or dUnit if you're a
Delphi shop, or cxxUnit if you're a C shop) can generate reports to
stdout that point your consultants at problems before they mess up a
business. If everything is validated with automated scripts as the
planning progresses against a pre-production testbed, then when the
migration itself is run there are far fewer problems.

It takes about a week to assemble the core of an automated test bed for
a data migration. Maintenance of the testbed is ongoing in small
increments as additional types of problems are detected.

3. Why do end users have/need DBA access?

The migration process itself needs DBA access. The end-user's DBA needs
DBA access. But no end user should ever need DBA access.

If someone else "needs" this authority, then discover what the problem
is that they need the authority to solve. It may be that there is a
market for some plugins or additional functionality that you hadn't
considered.

If the issue is resolution of migration problems, then identifying all
of the problems in an automated report (#2) should be the first step.

If the issue is problems introduced by poorly integrated foreign
systems, then adding audit information and (once again) the automated
report can work together to identify the culprit. Then, you may need to
provide a tool to fix the "broken" data, unless you end users are savvy
enough to not mess things up. A "fix" mode to your own software that
requires specific authorities, identifies problemsm but does not get
"broken" by bad data may be a low cost and robust solution.

If the issue is resolution of problems caused from within your own
system, the audit information and automated report can be used to track
down the faulty module and correct it.

I hope this helps.

On Tue, 2006-03-14 at 01:37 +0000, dbagregc wrote:
> --- In firebird-support@yahoogroups.com, Alexandre Benson Smith
> Thanks for your input. We and everyone else that might try this
> certainly need to realize that this is a hack and should be used
> with extreme caution. I will certainly try to find any downfalls to
> this before I make the switch, especially since our customers run
> their businesses using our software, and I would recommend the same
> to anyone else reading this.