Tim,

I'm not particularly fond of proprietary SQL statements/clauses, but one
common vendor extension I've found useful is the "if exists" clause, as in
the following example:

drop table if exists test;

In this context, the proprietary "if exists" clause is a short hand for
quering the metadata before executing the DROP statement. The equivalent
standard SQL statement would be:

if exists (
 select 1
 from information_schema.tables
 where table_name = 'TEST'
) then
 drop table test;
end if;

Seeing that you've implemented the metadata views in a schema named
INFORMATION, as opposed to the standard INFORMATION_SCHEMA, I tried the
following statement in the ElevateDB Manager:

if exists (
 select 1
 from information.tables
 where name = 'test'
) then
 drop table test;
end if;

The statement throws an error #700.

How is this type of statement supposed to work in ElevateDB ?

Additional questions:

1) Why not support the "if exists" extension in ElevateDB ? It's one on the
few proprietary vendor extensions that's really useful, since it's a short
hand for the full EXISTS statement and has a distinct meaning no matter how
the actual metadata is implemented.

2) Why implementing a proprietary "INFORMATION" schema (including
proprietary column names like "NAME" instead of "TABLE_NAME") when SQL:2003
defines the "INFORMATION_SCHEMA" ?

Finally, I'm not sure the decision *not* to support multi-statement blocks
(scripts) is a good one. A script is a very common way of creating databases
and database objects, including data.

Regards,
Ole Willy Tuv

Ole,

<< Seeing that you've implemented the metadata views in a schema named
INFORMATION, as opposed to the standard INFORMATION_SCHEMA, I tried the
following statement in the ElevateDB Manager: >>

I used a different name because the tables and views are different.  I
didn't want to give the impression that the schema was standard when it
wasn't.

<< if exists (
 select 1
 from information.tables
 where name = 'test'
) then
 drop table test;
end if;

The statement throws an error #700. >>

The IF statement can only be used in a stored procedure/function/job.  Did
you use it in the regular SQL window instead ?

<< 1) Why not support the "if exists" extension in ElevateDB ? It's one on
the few proprietary vendor extensions that's really useful, since it's a
short hand for the full EXISTS statement and has a distinct meaning no
matter how the actual metadata is implemented. >>

As I stated in another message, we stripped EDB down to nothing and built it
back up from there.  There are some extensions that could be added but have
not been added yet.  Some are apparently under the impression that EDB is
going to be as mature as DBISAM out of the gate, and it simply isn't.
DBISAM was developed over the course of 6 years, whereas EDB was done in 1.
It will get there, it's just going to take some time.  EDB was written from
scratch, with the only thing even remotely close to DBISAM being the
standard TDataSet components unit.  And then only barely.

<< 2) Why implementing a proprietary "INFORMATION" schema (including
proprietary column names like "NAME" instead of "TABLE_NAME") when SQL:2003
defines the "INFORMATION_SCHEMA" ? >>

Performance.  Using the INFORMATION_SCHEMA schema involved using views
instead of tables in a lot of cases, and the performance wasn't what I
wanted it to be.

<< Finally, I'm not sure the decision *not* to support multi-statement
blocks (scripts) is a good one. A script is a very common way of creating
databases and database objects, including data. >>

There are certain items that aren't going to make it into version 1 that
will be there shortly thereafter.  I had to stop developing at some point
and release since the project was dragging on and on with no end in sight.
Sometimes you simply have to stop adding things and call it a release.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<< I used a different name because the tables and views are different.  I
didn't want to give the impression that the schema was standard when it
wasn't. >>

As a general note - there's nothing wrong with extending the standard
INFORMATION_SCHEMA views with additional (proprietary) columns to expose
vendor specific metadata descriptors. Since ElevateDB SQL is based on
SQL:2003, I believe implementing the INFORMATION_SCHEMA would be a logical
choice.

<< The IF statement can only be used in a stored procedure/function/job.
Did you use it in the regular SQL window instead ? >>

Yes, I executed the statement in the SQL window in ElevateDB Manager.

Are you saying that I need to write a stored procedure just to drop a table
(in plain SQL that is) ?

<< As I stated in another message, we stripped EDB down to nothing and built
it back up from there.  There are some extensions that could be added but
have not been added yet. >>

Sure, I can understand that.

Ole Willy Tuv

Ole,

<< As a general note - there's nothing wrong with extending the standard
INFORMATION_SCHEMA views with additional (proprietary) columns to expose
vendor specific metadata descriptors. Since ElevateDB SQL is based on
SQL:2003, I believe implementing the INFORMATION_SCHEMA would be a logical
choice. >>

Yes, except we didn't, so you'll have to live with that.

<< Are you saying that I need to write a stored procedure just to drop a
table (in plain SQL that is) ? >>

To test first if the table exists with an IF, yes.  You could also just
execute the DROP TABLE and handle the exception at the client if the table
doesn't exist.

Again, are you just simply trying to stir up things Ole ?  Because I'm
getting that vibe from both you and Michael here.  Almost every message has
been you or Michael demanding that I justify a particular design decision.
Neither of you are principals in Elevate Software, therefore you don't get
to demand justifications from me regarding design decisions.  Things were
done for a reason, and if it's a bad decision on my part then I'll either
have to adjust it or live with the consequences.

If you want to report a problem, then go right ahead.  But try and limit
yourself to that.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<< Again, are you just simply trying to stir up things Ole ?  >>

Not at all. Since this is an early preview of ElevateDB, I thought you'd
want some feedback.

Seeing your reaction to my posts, I'll leave ElevateDB at this very minute.

Ole Willy Tuv

Tim,

> Again, are you just simply trying to stir up things Ole ?  Because I'm
> getting that vibe from both you and Michael here.  Almost every message has
> been you or Michael demanding that I justify a particular design decision.
> ....
> If you want to report a problem, then go right ahead.  But try and limit
> yourself to that.
I apologize if I sounded too demanding. I believe what I was reporting
are problems - maybe not bugs, but a design problem could even be worth
then a bug.

Anyway, I hear you and will limit myself to bug reporting.


Michael

Hello Tim,

> Again, are you just simply trying to stir up things Ole ?

Why are you so hard with Ole ? Ole helped a lot
DBISAM community and i don't find any reason been
so hard on him.

--
Charalabos Michael - [Creation Power] - http://www.creationpower.com -
http://www.creationpower.gr

Charalabos Michael wrote:

> Why are you so hard with Ole ? Ole helped a lot
> DBISAM community and i don't find any reason been
> so hard on him.


I don't want to speak for Tim, but I can relate from my own experience.
There is tremendous pressure to get a major product out.  Decisions
have to be made, and some of them are compromises. At some point your
design is final and when you release a beta into the world, the kind of
feedback you are hoping for is related to bugs on the product, not
design decisions that you made long ago.  Unfortunately you get both
types of feedback which limits your productivity, thereby decreasing
your patience level,  when the real information you are hungry for, is
actual bug reports on the product, unsalted by design wisdoms.

Once the pressure of the beta is over and the product is living in the
world, then all kinds of feedback are productive as you move into a
"next-version" mode.  Anyway, just my opinion.

--
David Farrell-Garcia
Whidbey Island Software, LLC

There is a history here, Michael; you are probably aware of it.
Furthermore, Ole is/was a consultant of NexusDB, IIRC, a paid
consultant. We all know that his intentions are for complete, pure SQL
2003. NexusDB made a big mistake in marketing itself as SQL 2003
compliant, because that gave Ole cause to completely rip it/them apart.
I haven't heard Tim saying ElevateDB is SQL 2003 compliant, thank God!

The fact is, as developers, we don't want to hear how our design
implementations are "idiotic, stupid, will never work, nobody will buy
your product", etc. If you think it is wrong, be nice, make a
well-thought logical case, and move on. If any of us strictly went by
customer demands, we'd *never* get our products completed.

My 2 cents,

Jason Lee

Charalabos Michael wrote:
> Hello Tim,
>
>> Again, are you just simply trying to stir up things Ole ?
>
> Why are you so hard with Ole ? Ole helped a lot
> DBISAM community and i don't find any reason been
> so hard on him.
>

Jason,

You pretend to know me and the design/marketing objectives of another RDBMS
vendor well. I simply need to chime in:

<< There is a history here, Michael; you are probably aware of it. >>

I'm not sure what *history* you're referring to.

<< Furthermore, Ole is/was a consultant of NexusDB, IIRC, a paid consultant.
>>

I developed the NexusDB V2 SQL documentation as a paid job. This task was
accomplished/ended 6 months *before* NexusDB V2 was released. After that
I've been doing QA on the NexusDB SQL implementation on a free/voluntary
basis.

<< We all know that his intentions are for complete, pure SQL 2003. >>

I've nothing against well-designed, properly implemented vendor extensions.
When I often refer to SQL:2003, it's because this is the current SQL
standard. I'm not sure if you're aware of it, but SQL *is* in fact a
standardized database language, defined and documented in the international
ISO/IEC 9075 standard.

It's not like RDBMS vendors implementing SQL should do whatever they want
under the cover that the implementation is *not* compliant, and if they do -
they should call their query language something different than SQL. When
implementing SQL, no matter syntax/dialect, there are a set of basic rules,
particularly how queries are evaluated and processed, the scope/validity of
column names etc. throughout the query context, one would expect to be
followed. As an example, SQL Server is very much aligned with the standard
SQL rules, albeit the SQL dialect, Transact-SQL, is proprietary.

<< NexusDB made a big mistake in marketing itself as SQL 2003 compliant,
because that gave Ole cause to completely rip it/them apart. >>

That's a bold statement.

As far as I see it, implementing SQL:2003 has been a tremendous advantage
for NDS and users of NexusDB. SQL:2003 is well defined and documented, which
makes it easier to implement and test. Besides, the NexusDB users know their
SQL code is evaluated according to standard, common rules in the RDBMS
industry, instead of proprietary rules *invented* by the vendor.

Ole Willy Tuv