🚀 go-pugleaf

In article <3608D97B.EE559968@intekom.co.za>, vanaardt@intekom.co.za 
says...
> I have a system using a Paradox table database written in 5.x.
> We are linking my system to another...this will involve simple and safe
> data transfers
> once per day.  The guys who wrote the other package are using Intebase.
> They requested me to transfer my tables to Intebase and assured me that
> I will
> not have to change any code???  My system is running fine on a Paradox
> table and I
> will not port my older clients to Intebase ,yet if it is as easy as they
> said - I can easily
> support a Paradox and a Intebase system.  What I have to avoid is having
> two sets of
> code - or to have to test and debug for both systems.

OK, if you use BDE Aliases to reference your tables it is pretty much 
transparent.  The worst stoppage I've ever hit is a conflict over 
unexpected keywords (commands and other internal functions) where I've 
had to rename variables, and sometimes fields. 

The only steps to conversion are to setup the IB-SQL Links driver, and 
define an Alias for it to use.  From there you should have the conversion 
tool in Visual dBASE to do the data conversion, or you can program it 
yourself in VdB.

This will get you a raw conversion of the data, and your prog should be 
able to run.  What it won't do is add the extra C/S gizmos like stored 
procedures and referential integrity.  You still have a desktop design 
although it may run from IB Server.  Reworking the ccode to take 
advantage of the power in the server is another stage, but this can make 
a major difference to performance.

> I also believe that for them to export to a paradox table won't be too
> bad.

There are serious advantages to the C/S model in terms of data integrity, 
I doubt they will even consider porting to Paradox tables as an option. 

-- 
pf