At 10:22 AM 15-04-02 -0400, Ed Malloy wrote:

>My experience dates back over a year. And my issue wasn't SERIOUS
>problems, it was the number of fixes and version updates (as can be
>doucmented from the version history of IBO and the IBO newsgroup
>archives). My decision was also based on the fact that the vast majority
>of the components were of no interest to me. I felt that a library that
>included just data access components was of more value to me.

Ed,
In view of your recent comments with regard to IBO, I reviewed
your "message history" in the few weeks when you were trying out
IBO. I remembered you as a Delphi and IB "newbie" and one of our
difficult cases...
So, to put your comments in context, here is a summary of
this experience:

Thread 1: Using TwwIBOTable.
The crux of this thread was that you were getting SQL errors from
using a column named Year. Several experienced developers explained
that, in IB 6, Year was a keyword and you would have to use double
quotes. At first, you pooh-poohed them all; then you changed the
column name to Yr and found it didn't work with your setup. As it
turned out, this problem arose because you failed to update the
persistent field objects and the column definitions of the grid when
you changed the column name (a "given" with the Delphi TDataset
architecture). Hardly to be attributed as an IBO bug, nor even a
Delphi one. Not an IBO bug but a lack of understanding of the Delphi
VCL.

Here some quotes from you during this thread:

"Year" is the same as "YEAR" is the same as "year".
thanks, but that's not it."

"I'm afraid that the interesting things don't include naming columns
using reserved words (or manipulating such columns). In general, I just
ignore the column - I've replaced it with YR, but it still sits in the
table and apparently TwwIBOTable tries an update with ALL the columns."

"What is really frustrating is the lack of documentation: for example
does the insSQL property allow me to specify the SQL statement used to
insert? If so, is the syntax "standard:"
INSERT INTO TABLE (COL1, COL2, ..., LASTCOL)
VALUES (:COL1, :COL2, ..., :LASTCOL)"

...also in this thread:
"Also, how do you "master/detail?" Do the links need to be FOREIGN KEYS?
or simply Indexed columns??"
[from the same posting]
"I am an experience prgrammer and experienced with SQL..."

Thread 2: TwwIBoTable and infopower grids

"I find most of the controls[sic] are essentially undocumented, and most of
the existing documentation understandable only AFTER I get the d**n
thing working."

You were using Tww... controls, which need TDataset-compatible data
access components in order to work...yet you were mixing it with native IBO
controls, which *don't* work with the TDataset-compatible access comps.
You never did work out the difference between a control and a data access
component, either.

...Although told by more than one person, as an "experienced programmer"
you never did grokk the Delphi inheritance model and go looking for
inherited TDataset properties and methods in the Delphi VCL help. Because
they weren't in the IBO help file, they weren't anywhere.

You seemed to be using a merry old mash of TDataset-compatible and
"native IBO" components at times, as well.

Thread 3: IBO Help Files?

"I wish that Jason would stop rushing forward with this that and the
other thing and take time to debug the existing controls and to write
good solid, usable documentation."

(At that point Jason and the whole IBO community were engaged in beta-
testing release 4; the IBO 3 help file weighed in at just over 6 Mb.)

The point you seemed to miss was that it wasn't the role of Jason or
the IBO community to teach you Delphi or SQL. It wasn't more IBO help
you needed to understand why your statements failed or why your GUIs
broke when you altered the structure of a table.

In the same thread:
"So far I am using only the IBO... controls, IB_Connection and
IB_transaction and my current front end of mainly infoPower & orpheus
controls."

For those who don't know (including you, apparently), the IBO controls
and the other two IBO components you mentioned here belong to the "native
IBO" suite and are not compatible with Infopower and Orpheus controls.
You needed to be using all TIBO* components and NO TIB_* comps at all
not data access, not controls...but you wouldn't be told.

More in this thread:
You: "It just seems to me that there are an enormous number of controls that
are very nice, but peripheral.. for example the accounting controls.

Jason: "Accounting controls? I'm not aware of any such controls.
If you mean the TIB_Ledger control, that was primarily developed by someone
else and contributed to IBO. Considering the time it took me to merely port
it to the native IBO architecture it was a bargain."

You: "Yes, that's the one."

"IBX conversion was a no-brainer. Absolutely no conversion problems;
The TIBDataSet works exactly as I would like. Our applications are not
extremely complex, about 30 basic tables plus anilliary tables.
They do order-entry/fulfillment and the management. I could never quite
get IBO to work the way I wanted it to work."

"I was never interested in replacing my infopower grids nor my orpheus
data edits, so that part of IBO never interested me."

As you commented, going over to IBX was a no-brainer. That was my
experience, to, when I tried it out (which I did, before I ever looked
at IBO). I think it is quite possibly ideal for the table-based, GUI-
driven style of development you do. If you are dedicated to writing
apps that pull everything over to the client and just push results back
over the wire, what use could you make of OAT management, server-side
filtering, callbacks or server-responsive searching?

When you finally opted for IBX, I must confess it was a relief to me.

regards,
Helen










All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org ·
http://users.tpg.com.au/helebor/
_______________________________________________________