At 01:11 AM 13/02/2003 +0100, you wrote:

>My SQL was like this:
>
>SELECT
> *
>FROM
> INVOICE
>
>...and the trouble:
>
>Table INVOICE doesn't exist.
>Or - it doesn't have a PRIMARY KEY.

Well, these are two different problems.

>Both of these cases results in an added field
> ", INVOICE.RDB$DBKEY"
>..which is rather pointless for more reasons:
>
>a) The select statement is no longer valid SQL syntax

What you got was the IBO parser's attempt to make sense out of bad
SQL. The parser itself doesn't know it is bad SQL until the DSQL parser on
the server throws an error at prepare time.

>b) Why on earth add this info when I only want to make a select call ?

Because IBO needs to have a unique "handle" on each row, for use when
swapping rows in and out of the buffers. Because you didn't supply it (via
KeyLinks) and asked IBO to try (KeyLinksAutoDefine True) then IBO tried to
do it. It failed because of another error in the statement.

>c) Why couldn't the real reason be detected - that valid row identifier
>field(s) cannot be added ?

They can, provided the original SQL statement was valid. Your particular
combination of SQL errors caused a rubbish statement to be generated, but
the appending of the rdb$db_key itself is valid.

Take it from me, AVOID select *. It is there to comply with standards but
it is not at all appropriate for use with an interface that implements
behaviour that has the client buffers interacting with the cached output
set on the server. If this conflicts with your requirements, you probably
need to use ODBC, not IBO.

>d) After error message is issued, there is, AFAIK, no way to read the
>failing SQL call from the TIBOQuery. Too bad, as you do now have a detailed
>spec on where error occurred, but unfortunartely - not the original SQL stmt
>itself.

If you are watching the API with a TIB_Monitor then you will see everything
that goes through the API. If it isn't what you expect then it's a sure
sign that the sum of your application's requests is different to what you
intended.

>And now, the final quesions:
>- Why isn't the source built up by .pas files ? The include files result in
>loss of syntax highlighting, makes searches hard, separates declarations
>from source body.

The IBO packages are built with a lot of conditional defines, so that the
same sources work, regardless of Delphi version and edition. When tracking
through sources, just press Ctl-ENTER to jump to any unit ref'd in a USES
clause.

>- Why is portions of code loaded with HTML within comments ???

Because we use Time2Help to generate our helpfile. It lets you use javadoc
and html tags to customise the help text output. The INT files contain the
interface section of the corresponding PAS units. We put the help text in
the INT comments so that it is all in the right place for maintaining and
so that it can propagate to the descendant classes.

>I must say, this day I have started thinking about whether the "IB move" was
>so smart after all. Loads of nice features make the components fragile.

Fair comment, IBO needs a lot of skill with the OO features of Delphi and a
good understanding of SQL. We did the GSG to address the steep initial
learning curve but, even with the GSG, you need a fairly high base level of
Delphi and DB skills. If you are new to client/server and haven't
previously needed to get in touch with Delphi's object model, then it's
quite true that the curve will be steeper.

This isn't a put-down - it's a personal observation of my own
experience. I had the same frustrations as you to begin with and rejected
IBO for a very important project in 1997 because I simply didn't know
Delphi well enough. Three years later, I had to make myself do it, because
Jason asked me to write the GSG. The original version of that guide was
the very direct result of that effort - me starting with IBO literally from
Ground Zero.

>I've also been bothered with seemingly random accessviolations upon startup,
>especially after a crash. Some of these crashes are just overseen with a
>brutal exception handler, so it won't bother a user. But it bothers me.

I'd want to investigate why you get crashes and I would treat the AVs
afterwards as a symptom of what caused the crash.

>Of course - a component vendor's coding style is normally no business of
>mine. But in this case I *need* sources to be able to determine source of
>problems, and features that are not documented. I find it almost unreadable.

There are some FAQ items regarding the structure of the sources, which
might help. Also, get familiar with the IDE tools for exploring linked
source files.

regards,
Helen