""Alan McDonald"" <alan@...> skrev i melding
news:NBBBJKLIEJPCMJJOFDNPGEMDFAAA.alan@......

> *, fieldname
> as a select list is invalid
> you'll need to list the fields completely
> Alan
>

My SQL was like this:

SELECT
*
FROM
INVOICE

...and the trouble:

Table INVOICE doesn't exist.
Or - it doesn't have a PRIMARY KEY.

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
b) Why on earth add this info when I only want to make a select call ?
c) Why couldn't the real reason be detected - that valid row identifier
field(s) cannot be added ?
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.

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.
- Why is portions of code loaded with HTML within comments ???

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.
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.

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.

I hope someone can show me there are simple things that I've missed....

Thanks in advance !

Regards,

--
Bj�rge S�ther
bjorge@hahaha_itte.no