Thanks Max. I'm already into that, and more or less decided it is the most
efficient all round solution. Less work to implement as well.
I was really probing to find out what others are up to in an endeavor to
broaden my horizons a little.
I'm not at all sure about the flying objects scenario. When you get down to
the nitty gritty its hard to imagine how this can result in lower average
network traffic.
I can see that using interfaces results in a more elegant solution, and
offers the opportunity to use patterns, but once again, just like removing
the BDE, I don't see why the hell this should be a design goal in its own
right.
Seems I'm missing the plot with so many telling me I should get into flying
objects. I took a look at this stuff a cupla years ago and wasn't taken with
it. Guess I better take another look and get educated. Ah but how? If you
aint in the in club, then its pretty hard to get to know it.
Kerry writes a pretty compelling argument. The least I can do is take a
closer look at it all.
-----Original Message-----
From: Max Renshaw-Fox <[EMAIL PROTECTED]>
To: Multiple recipients of list delphi <[EMAIL PROTECTED]>
Date: Monday, 6 September 1999 07:15
Subject: RE: [DUG]: Thin Database Components.
Tony,
What about the solution that Wade organised in Aus, where the major smarts
were just in caching the lookups with client datasets.
I've been doing some stuff recently, which is also essentially 2 tier but
all in stored procedures at the back end with minimal data travelling up the
pipe. Delphi is then really a display engine, with stuff that I need cached
locally.
I'm not moving a lot of data, and it's not really high-transaction stuff (so
I can afford to get most data once only) but then I can't see how you can
avoid moving the data that you need the user to see anyway.
Max
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Tony Blomfield
Sent: Thursday, 2 September 1999 20:16
To: Multiple recipients of list delphi
Subject: Re: [DUG]: Thin Database Components.
Thanks for the replies.
Bypassing the BDE is not an objective in itself. By "Thin" I am referring
to designing applications in such a way as to minimise the network traffic,
the objective being to make the app run as fast as poss over a narrow pipe.
(56K Modem) Take a look at a telnet session into an AS400 as an example of
"Thin" within this definition. I am not a three tier expert, but I find it
hard to beleive that a three tiered object brokering approach can be an
efficient model for slow networks, although there are other advantages in
usnig DCom Corba etc.. It seems to me that using optimised data access
components like FIB and the Oracle equivilent (I never can remember the
correct order of the Acronym for the oracle components) would offer the
thinest approach possible..
So, does DAO fall within the scope of my goal? or does it drag objects
accross the network also.
Thanks,
Tony.
-----Original Message-----
From: Nic Wise <[EMAIL PROTECTED]>
To: Multiple recipients of list delphi <[EMAIL PROTECTED]>
Date: Thursday, 2 September 1999 5:19 PM
Subject: Re: [DUG]: Thin Database Components.
> So if something is OLE DB capable then it is apparently a short step from
there
> to ADO which of course means the BDE is bypassed.
>
OLE DB = driver for ADO.
ADO-MD = multi dimensional ADO, ie OLAP, which is rather cool...
N
--
Nic Wise - +64.21.676.418 - +64.9.277.5309 - [EMAIL PROTECTED]
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
