At 12:42 AM 11-08-02 -0400, you wrote:

>Helen,
>
>I should explain how I "chose" the components on my form. I have found in
>the past that, when becoming familiar with a new development paradigm, the
>best way to get started, while staying out of the swamp (I live in Florida),
>is to modify a working product. I started with example projects that looked
>like they apply to what I need to do. I derived my forms from
>Masterlinks.dpr and MasterDetail.dpr.
>Those were working fine in the
>original. I then tried to move that structure to my app, and that is how I
>ended in this predicament (i.e., swamp).
>
>Am weighing my options as to which of the two examples is better for my
>application. At present it appears that I will use both for different parts
>of the project. Anyway, am somewhat perplexed that the examples show one
>way of doing things, and you suggest another, which I have also, somehow,
>managed to break. Perhaps you could point me to other examples that embody
>your approach within a structure that resembles MasterLinks or
>MasterDetail, that I could use as a point of departure.

Hmmm. What I suggested wasn't a "different approach". As I said,
TIB_Connection and TIB_Transaction are not incompatible with the TIBO*
stream dataset comps but TIBODatabase is purpose-built to combine the
properties and methods of those two components and provide the same kind of
transparency to transactions that you get in the BDE. What I suggested to
you was a way to do what you were trying to do, without the complication of
taking care of the transaction yourself (since you have only the
one). Getting your head around transaction control isn't usually a
five-minute exercise...and, as the pennies start to drop, it will become
more obvious how multiple explicit transactions can help you meet
requirements. Then, if you are using TIBODatabase, you can move into the
world of multiple transactions by adding TIBOTransactions to it.

Most of those samples are pretty old and, for all I know, the
MasterDetail.dpr sample was created before IBO had a TIBODatabase. (fwiw,
the native IBO stream also has a TIB_Database, so you can have the same
concept for TIB_* components too, if you want. I don't think there is a
sample there using TIB_Database, though.)

>Meanwhile, I'm going to go back to the original projects and see if I can
>make them work with your components.

Not *my* components!

They are two different sets of components. The ones with class names
starting TIBO* are referred to as "TDataset-compatible" because they
inherit from the same base classes as do the native VCL data access
comps. Really, I think a more apt term would be "TDatasource-compatible",
since the key point is that these comps link to native VCL data-aware
controls through the TDatasource; and can be used with any third-party
data-aware controls that use TDatasource or its descendants for
datalinking. I mention this particularly in your case, since I know that
you are a long-time user of WebHub, whose data-capable components link
through TDatasource descendants.

The ones with classnames starting with TIB_* are the native IBO components
and controls. The native IBO data linking uses a TIB_Datasource, which is
incompatible with the TIBO* dataset classes. TIB_Datasource links the
TIB_* data access comps to the TIB_* data-aware controls. TIB_* controls
can't be used with TIBO* data access classes; and TIB_* data access
classes can't be used with the native VCL controls nor with third-party
data-aware classes designed for use with TDatasource or its descendants.

For WebHub, use the TIBO* data access; and make life simple for yourself
by using TIBODatabase. If you are doing non-Webhub developments, you have
many more choices and a slightly steeper learning curve (well worth the
effort, though).

You *can* hybridise your apps and include the TIB_* dataset classes in the
same forms where you have TIBO* for your visual stuff. You don't need
TIb_Query, since TIBOQuery fulfils your need for a scrollable dataset; but
TIB_Cursor is very useful for situations where you want to either pull data
across to load into a stringlist of any sort; and TIB_DSQL is great for
sending DML for immediate execution. Both of these comps link happily to a
TIBODatabase. The beauty of these two babies is that they don't have the
overhead of a buffered dataset and all the activity that is built into
them. They are real resource-savers. fwiw, I've always considered that
the scrollable dataset was a terrible waste of resources in WebHub (and
other n-tier tools as well); but the old BDE data access architecture
doesn't provide the options.

You can do very fast, robust server apps with the non-scrollable
dataset; and there always was a lot of potential to enhance WebHub's
connectivity for InterBase using native IBO.

>BTW, I resolved the password issue with your help.

Good. :-)

regards,
Helen Borrie (TeamIBO Support)

** Please don't email your support questions privately **
Ask on the list and everyone benefits
Don't forget the IB Objects online FAQ - link from any page at
www.ibobjects.com