> -----Original Message-----
> From: Ed Malloy [mailto:edm@...]
> Sent: Lunes 15 de Abril de 2002 16:23

> In
> this group my comment had to do with the fact that
> a.) "buggy, buggy, buggy" intended to imply that the components
> were relased for sale without thorough testing, and

I think one measures a component suite not for the exact number of errors,
but for the severity of the bugs. How much gymnastics do you do to avoid the
suite's bugs? How fast is the answer from the supporter, be it recognition
of the bug or bug fix? How do the bugs rate against the complexity of a
package? For example, both IB and FB are plagued by virtually thoousands of
minor and some major bugs. Despite FB having maybe 300+ extra bug fixes, it
still fails. One should decide to what extent a server or product or add-on
is unusable. There are at least two models: one where bugs are threw under
the carpet for the "major next upgrade" that may be 10 months ahead (or may
mean a new version that you have to pay for) or one where the product
evolves and gets fixed daily. At this point, which model you prefer is
technical and personal preference. The thing "released without enough
testing" is hard to measure. I could say the same about DataSnap or Variants
support in D6, for example (not for nothing Borland decided to create some
weeks ago an open beta test and its NG for Variants changes that will be
released in the future).

> b.) there were more components that I needed or was interested in using.

I once bought Infopower because with a colleage we planned to use it and
used it indeed. We took advantage of 50-70% of the components. I would have
acquired Orpheus with enough budget, too. However, it will be very difficult
to locate the suite that offers no more nor less than the components I need.
In the best case, I can see fit for more components as my application
progresses or I gain more confidence with the suite. Certainly, had I needed
only a grid with coloured column titles and nothing more, I wouldn't have
wasted money to get Infopower's "ridiculously" supercharged grid. If you can
use a basic suite, use it. However, if you find reinventing the wheel in
each application yours due to the primitiveness of that suite, you may want
to switch to a more complex suite where another person went already through
the hassle of making the mistakes you may do if starting from scratch.

> FWIW I have used Delphi for as long as Delphi has existed; prior
> to that I worked mostly in C. I have programmed in SQL for as
> long as I have been working with database. I would hazard a guess
> of 20 yrs.

I've used C++ for 11 years and Delphi since May-1995 (D1) or so and
previously to Delphi I played with some IBM SQL tools. However, years do not
translate automatically into knowing all corners of a tool or language.

> As for the Year issue:, of course the "so-called" experienced
> programmers were wrong, since ... t1."Year" ... FROM table t1
> does not work (and never did w/v6 afik)

To avoid us laughing at you without reason, Ed, I think you should do
yourself a favor and explain why and where it fails. Does it fail in plain
isql that uses the API and GDML? Does it fail in IBConsole that uses IBX?
Does it fail in IB_SQL or Marathon that use IBO? Did you experience a
failure specifically with IBO or more specifically even with IBO's
compatibility TIBO* components? If you are saying "never did w/v6" then you
are referring to the engine. THE ENGINE DOESN'T FAIL AS YOU ARE SAYING. Dear
20-years experienced SQL programmer, you are utterly wrong.

This is not a fake session. I just did it now:

H:\ibdev\fbbuild\interbase\ib_debug\bin>isql
Use CONNECT or CREATE DATABASE to specify a database
SQL> create database 'think_before_writing.gdb';
SQL> create table tbl("Year" int);
SQL> select t1."Year" from tbl t1;
SQL> insert into tbl("Year") values(2002);
SQL> select t1."Year" from tbl t1;

Year
============

2002

SQL> commit;
SQL> ^Z

I also launched IB_SQL, made with IBO and activated the Browse button.
Inside it, Relations tab then Data tab. The column with the mixed-case name
is shown properly together with its value. As it's not enough, I went to the
simple Cursor tab in the main window and did
select t1."Year" from tbl t1
and again got the correct result. Notice my IB_SQL is based on IBO3 and
compiled with D3.

> I presume that I could
> go into the the interabase system tables and remove the column,
> but since it isn't bothering anything I have left it there.

Ok, I'm going to reconnect and show you that your presumption, while
correct, is unnecessarily bothersome and error-prone. I will rename the
field with standard commands to a name that doesn't conflict with keywords:

H:\ibdev\fbbuild\interbase\ib_debug\bin>isql think_before_writing.gdb
Database: think_before_writing.gdb
SQL> alter table tbl alter column "Year" to yr;
SQL> commit;
SQL> select yr from tbl;

YR
============

2002

SQL> ^Z

Now the field name is not only case-insensitive, but it can be used in
dialect 1 as well, because it doesn't clash with any keyword.


I think this leaves no doubt:
a) The original SELECT works in both isql and IB_SQL.
b) You can rename the field with the standard DDL commands.
c) Had your db being dialect 1 (you said NOTHING), you had used gfix to
switch it to dialect 3, do the DDL command and change it back to dialect 1
to avoid fiddling with system tables. This small roundtrip
needed to be able to use quoted identifiers temporarily to rename the
offending field. However, if your db was dialect 1, then using legitim
techniques, there's no way to create a case sensitive field neither a
keyword-named field, so I think your db was always dialect 3 and hence there
was no problem accesing the "Year" column.

> I
> think that this is a nearly perfect example of some of the bad
> advice you can get here from the half-baked experts. As with any
> "free-lunch" you get what you pay for. I know that there is also
> very good advice available here, but one needs to be able to
> seperate the wheat from the chaff.

It's easy to criticize, denigrate and piss others when you get peer support
in good faith and for free. Nobody guarantees that flux to be bullet-proof.
Heck, even paid support goes wrong several times with any product from
reputable companies. Given my output shown above, it turns out that the
half-baked experts and even the crude experts weren't so wrong. The SELECT
command is doable, the renaming of the field is also doable using DDL,
without resorting directly to system tables. Probably what the half-backed
experts didn't do was to take your db for free personalized troubleshooting,
I conclude. Anyway, I don't have any idea where that thread might have
happened. I guess it happened inside the IBO list. And I don't understand
what your problem was without enough information.

> I do enljoy the way 6 or 7 of the people on this newsgroup
> pull together when you feel threatened.

Probably Jason pays a group of people to hush up anybody that doesn't like
IBO, according to your paranoia.
:-)

In the time I used IBO, nobody smacked me or tried to skin me for posting a
bug or complaint in the IBO list.

> Let me try and make it
> clear: I was never and am NOT denigrating the IBO effort, I
> simply was and AM saying that is that IBO was not for me, and may
> not be for other people either.

Being myself a person that enjoys the sarcasm, I disagree. Your first post
said textually at the end «(gee, sort of sounds like an unnamed nw US
software company, doesn't it!)» including the typo that I think is "new".
And you were referring to CPS (Jason's company). What do you expect? Jason
laughing? Try to make for example the same joke at the FibPlus forums and
see if you get flack or not.

C.
---------
Claudio Valderrama C.
Ingeniero en Informática - Consultor independiente
http://www.cvalde.com - http://www.firebirdSQL.org