> >
> > >Actually, Paradox has had RI since about version 5 or so, but

it's not

> > >often used and was not retrofitted here.
> >
> > You mistook what I said. Paradox doesn't have declarative RI. It
>
> You're right, I did <g>. Sorry.
>
> And now I have a real question. I'm writing a program to convert the
> PDX data to Firebird. With the constraints in place, copying one table
> at a time doesn't work well unless I choose just the right order. To
> complicate matters, this conversion will have to be run unattended

(or at

> least by very unsophisticated users) at about 1000 sites, so whatever I
> do can't involved much human activity.

We had to bite the bullet and refactor a significant number of tables,
introduce generator driven primary keys and alike, so out conversion
tool was quite complex (and slow). If the structure didn't change too
much, then perhaps a straight data pump may be possible, but it wasn't
practical for us.

> In the past (i.e., when this was a DBA's problem) I've seen them do

things

> like remove all the constraints, copy the data, then reinstate the
> constraints.

Reinstating the constraint will cause an exception if the data
violates it. The more complex consistency rules that you write using
triggers are much harder because the triggers don't run when you
re-enable them.

A bigger problem than discovering broken consistency rules is deciding
how you are going to handle them. Are your users smart enough to ask
them which one to remove, or is the judgement process objective enough
to decide within your application logic.

The short answer is that there is no short answer. Pretending that
there is a short answer is what causes most consistency errors in the
first place, and not dealing with them now won't make them magically
disappear later.

What you are trying to do is to port a piece of software designed
around a desktop database to a run of client server database engine
with no code change more complex than using Replace Components in
GExperts. I totally understand your dilemma and time constraints
because I have been in that boat. I'm afraid that the foundations of
your software are not well designed for client-server, and this will
bite you at some point in time. You may get it to run, but it will be
buying time until you have the oportunity to fix the underlying design
problems.

2 years down the track, there are still some modules in our software
which were clearly designed around a desktop database, and no points
for guessing which modules cause the most problems.

Adam