From: "Louis Kleiman" <lkleiman@...>

> This thread has really moved away from IB/FB, but I will make another
> comment. I welcome a private dialog if you like.

It is a support group after all. Even though this particular thread is
slightly off topic, a well meaning thread is occasionally allowed to
continue to give others a chance to learn from it. Along that vein, I hope
that the pointy-hatted HeLen :) will let it go just a little longer.

>
> 1. Your view of Borland's responsibility isn't necessarily theirs.
> They seem to be creating a tool that can perform a vast array of tasks
> by reusing components. I don't consider it particularly onerous to drop
> more components into an application if it is what's required to get the
> job done. In fact, if all you want to do is edit a single table, the
> xxDataSet, Provider, and ClientDataSet aggregate to a single component
> in Delphi 6 e.g. the IBClientDataSet. If you want to edit more than a
> single table, Borland has provided a means to do that as well via what I
> think is a pretty good class decomposition of the problem.

Agreed that our views don't always coincide. However, even the
IBClientDataset is being touted as having problems and so shouldn't be used
seriously right now. If that's changed, I apologize, but in most posts I
read on Borland, that seems to be the going consensus. What I should have
clarified, but didn't, was that all my forms have already been converted to
pulling only the current (master) record at any one time, not a whole set of
records to work with. Since I've already spent many man hours streamlining
this technique and building the procedures to find the first, next, previous
and last records, spending even more time just to disconnect from the DB
during editing doesn't seem to me to be necessarily productive.

> 2. I have actually taught and led teams that have migrated larger apps
> than the one you mention from live queries and TTables to the CDS
> mechanism, so I can do more than imagine it. No, it isn't fun, but
> neither is the performance and lack of flexibility of applications built
> using non-CDS architectures. Dynamically created queries make the task
> slightly tougher, but not at all undoable. I have developed some pieces
> in this area as well. Let me know if you would like to move and want
> any advice/help.

If I were in a shop with other programmers who could help, it might not be
as bad a prospect as it seems now. However, I am a single custom programmer
without the means to "hire" any additional help so it falls on me to do it
all. While that is by no means an excuse for sloppy or even bad work, it
does mean that time is slightly more limited for what I can do versus what I
could do, especially for existing apps that started before client datasets.

> 3. There is also an unsaid benefit here - the lack of being tied to a
> particular DB platform. In the CDS-based application, most of your code
> resides in the CDS and the DataSetProvider. These components are in no
> way tied to any DB platform. Thus, to move to another platform, I spend
> my time rewriting SQL as necessary and asking GExperts to change my
> xxDataSets to yyDataSets, not rewriting and rehooking event handlers. I
> am about to embark on a migration of 4 applications from 1 platform to
> another. Two of these applications are CDS-based and will move in a
> couple of weeks (plus a bunch of QA). The two that are not CDS-based
> will probably take six months or more to move.

It took me (by myself) about 2 months to move my main app away from Access
which it was originally built for, to IB. Most of it was incompatibility
between SQL syntax. I have a feeling that this is the major issue whenever
moving between any databases since they all use some different syntax. Just
look at the discussions regarding the growing differences between IB and FB.
If you want to write an app that works with either one, you are limited to
using only a subset of either one's functionality or you risk problems later
on. The other bulk of time was spent moving completely away from tables and
into queries, even for simple lookup grids controlling setup/lookup
information.

In closing, let me state that I understand the importance of separating data
access in the program from the actual architecture being used, but this
isn't always possible for other reasons. As it stands now, I don't intend to
support anything but IB (or FB) but if that changes in the future, only then
will I be forced to spend the time looking at converting everything to
client datasets.

Woody (TMW)

----------------------
"I don't know the key to success, but the key to failure is to try to please
everyone."
-Bill Cosby