> Can someone confirm the following findings?

Thanks for shedding light on this important area and sorry I didn't respond
more promptly. The rollout I've been working on has really been a time
miser...

> 1- The IB_Session property of IB_Connection and IB_Transaction can only
> be set by code, not at design time.

This is a current limitation, yes.

> 2- The IB_Session of IBODataSet is read-only.
> InternalDataSet.IB_Session can be set by code, but internal
> IB_Statement objects created for fetches, lookups, etc. invariably get
> bound to a "default" IB_Session, thus defeating the assignment and
> generating all kinds of interesting effects.

This also is currently a potential problem.

> 3- Once a IB_Session component is put on a form, it becomes the
> "default" session for all IB_Components on that form. All other
> IB_Session components are ignored unless I use them in code, which
> takes me back to point 2.

I believe this is correct.

> 4- The components apparently don't check session coherence. IOW, I can
> have the usual IB_Connection, IB_Transaction and IB_Query bunch, link
> them together and link each of these to a different IB_Session without
> getting errors until late in the form of strange effects, assertions
> and AVs in the client library.

It is true that session management in IBO is not so flexible because I have
had the luxury of a single DLL file to attach to. Now that we are having
multiple clients to potentially connect to it makes good sense to bring the
TIB_Session referencing system up to date with full flexibility both at
design-time and at run-time.

I envision being able to drop multiple session components onto a form and be
able to hook them up at will.

The alternative that I am still pondering on the benefits of, would be to
keep the monolythic TIB_Session scheme as it is and enable it to broker
between the various client interfaces. Then, there would be a driver-like
setting configured at the connection level.

> Does anyone care to explain in what exactly does IBO's IB_Session
> management differ from the old BDE TSession thing, or point me to the
> appropriate documentation? I have looked in the help file and studied
> the source, but I might have missed something. If there's nothing I
> have missed and things actually work like I observed then I think it's
> flawed or at least not flexible enough - I think it is reasonable to
> expect to not have to rely on component ownership to distribute data
> access components across sessions.

There is actually quite a bit of differences between the old BDE session
stuff and the IBO session stuff. My goal was to try and simplify session
management and make it able to drop into the background as much as possible.
In short, there are three usage cases I looked at and felt satisfied that
covering them was sufficient for all developers needs (at the time 8 years
ago).

Case 1: Gui application with no multi-threading. Didn't want anyone to have
to do anything with the session. Introduced TIB_SessionProps to get at the
default session's properties. Was nothing more than a way to supply those
values at design-time.

Case 2: Multi-threaded application that uses datamodules or webmodules, etc.
Drop a TIB_Session component on it and make it first and then have
everything else automatically hook up to it as its session. Kind of like an
automatic homing device.

Case 3: No particular modules or application style. Everything in code. In
this case I use the Ownership chain as the path to session resolution. Each
time something is created it is sensitive to what thread it is involved
with. Thus, right at the time of creation the session referencing is
immediately important. Thus, it made sense to me to have the object creation
scheme be coupled with the session referencing scheme.

The blind spot is if someone doesn't know to use the above conventions (IOW,
they didn't read documentation) they may assume it is save to create objects
with a NIL owner. IN IBO this could be a potential source of problems if you
have nil owner objects that are tied to the default session being used from
multi-threading environs.

I am very much open to suggestions and additional cases I perhaps didn't
think of that I should have. I am also keenly interested in how people would
like to see these new client API's to be simultaneously attached to in one
application and potentially even switched on a single run-time session.

Regards,
Jason Wharton
www.ibobjects.com