🚀 go-pugleaf

On Mon, 13 Sep 1999 14:49:12 GMT, tonylees@datarev.udashnet.com (Tony
Lees) wrote:

>We are investigating re-writing our legacy (Cobol) applications in
>Delphi.  We would like to be able to have the one application running
>and let the customer choose which  (supported) database they have,
>whether it be Paradox, dBASE, Access, MS-SQL, Interbase, Oracle etc,
>and whether local or client/server.
>
>Whilst it is clear that Delphi supports any of the above, either
>directly or via ODBC, can it support all the above from the same code
>- and are there any major downsides to doing this.
>
>The literature and sales people are vague and don't quite answer the
>question.    
>
>Our market covers cost sensitive single to 5 user sites, and up to 100
>user sites with Oracle or similar.  There are many data files,
>including accounting functions, and we expect at the larger end to be
>handling 400,000 records.  It is obviously attractive for us to have,
>as near as possible, the one application.  

There are a couple of issues you will have to solve properly.

The first issue is efficiency.  Desktop dbs have to be accessed
through tables, indexes and ranges to be quick (especially with the
numbers you are expecting), while queries are much better on C/S
databases.  You should handle this by having a double set of datasets.
A set of tables for desktop dbs and a set of queries for C/S dbs.  It
is easy to incapsulate this in Delphi (probably in a datamodule)
because most data-aware components point to a TDataSource object which
in turn points to a TTable or a TQuery result set, and most components
don't really know the difference.  Most of the code will have to
reference a generic TDataset or TBDEDataset and not a specific TTable
or TQuery.

The second issue is that while C/S dbs, like InterBase and Oracle,
provide a trigger and stored-procedure language and strong data
integrity constraints... this is not so on the desktop databases.  And
triggers and stored procedures are not portable even among the
different C/S databases.  So you either leave them out or provide for
some differences in behaviour among the dbs.  Probably the easiest way
is to leave integrity out and implement all constraints on the client
application.  This is easy but I do not recomend that you ignore the
additional potential of C/S data integrity.

The third issue is that *some* features are not supported by all dbs
or behave differently.  You will probably have differences in the
record locking mechanics among the different dbs (pessimistic vs
optimistic requires a slightly different client application logic).
You might have some problems with indexes among the desktop dbs (you
could try to avoid composite indices and dbase unique indices).  You
must avoid autoincrement fields.  You should beware that not all dbs
support all the Delphi field types (so beware of memos, float,
currency and date/time/datetime).  Beware of M$ Access as is seems to
present a whole set of specific problems.  Most of these things might
not cause obvious errors, but might cause some subtly different and
strange behaviours.  You will probably have to use the few common
feature of most dbs, avoiding where possible specific features
supported by one single db.

Anyway... good luck... I don't know of anyone that succeeded in this
task... but I think it *is* possible.

Regards,

--
Marco Rocci
MicroEra srl
Turin, Italy
-----------------
vota contro lo SPAM su: http://www.politik-digital.de/spam/

>Anyway... good luck... I don't know of anyone that succeeded in this
>task... but I think it *is* possible.

that's the point :-) 

ciao, jan 

dokumentenmanagement und mehr: http://www.rsp.de/ vertriebspartner gesucht!

mrocciNOSPAM@tin.it (Marco Rocci) wrote:

>
>Anyway... good luck... I don't know of anyone that succeeded in this
>task... but I think it *is* possible.
>

Thank you for your considered reply.  We certainly don't want to get
involved with creating non-standard approaches, or doing something
that no-one has ever done before.

It seems that we probably will be best adopting an SQL/Client-Server
approach using Interbase and tackle the issue of other databases when
the situation arises.  

Do you have any feel for how comprehensive LOCALSQL is?  For instance,
if Paradox was used, will LOCALSQL place limitations on what can be
done - or are all the "normal" database functions catered for?

With thanks

Tony Lees

Put a dash instead of dash if emailing me