> If it really was a showstopper you could still have used
> ClientDataSets,
> running dbaware controls off them.
and limit your data representation to tabular format ..., plus your business
rules will be ties to data controls, ie, UI. No reuse here.
> >Then there's always the problems of queries -
> >the drama involved in updating a record returned in a
> read-only result set,
>
> There are various non-dramatic ways to skin the "read-only
> result set" cat.
> Eg., using RequestLive and CachedUpdates true:
Surely you must be joking! CachedUpdates? That creates paradox files all
over the show! Its a nightmare - the ultimate in fat client technology!
Just imagine, *WHEN* your program crashes, it leaves these MB files in the
client's hard disk - it soon fills up.
RequestLive can only work if:
a. The query is very simple, like an address book type query (select * from
table - you might just as well use TTable), not generally suitable for C/S
programming. Can't use joins.
b. The datasource supports updates - which means no stored procedures, or
complex views.
Better to have rich objects, cache the data in your objects, and when the
user finally hits the save button, call the persist method. This then
ultimately fires off queries to the backend. With rich objects it is also
easier to support undos.
Furthermore, keeping queries open with RequestLive, etc., means you need to
keep more handles open than necessary. With our web server, there is only
*ONE* database connection, and at most 3 query handles open at any one time.
Regards,
Dennis.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
