What are the differences between DBISQL and dbisqlc w.r.t. query processing?

[VolkerBarth]

Obviously, there are lots of differences in the functionality between DBISQL and the deprecated dbisqlc tools, e.g. DBISQL's editable query result window, import/export facilities, editing, source code integration, different input/output formats, locking of result sets, and much more. - And surely there are not so obvious ones, too.

But what are the differences when it comes to query processing, i.e. is the assumption correct that both tools should handle the same query identically (well, except for locking issues)?

I do raise this question as there seem to be some syntax variants that are handled differently by both tools, e.g. EXCEPT statements enclosed in parantheses.

Are there some general differences in that respect, or are they just unwanted and only based on the frozen dbisqlc parsing?

(If the answer is version specific, I would like to get an answer for v12.)

[johnsmirnios · Accepted solution]

In short, I don't think anyone really knows the answer to that question. Dbisql is under active development and I'm sure that team knows it inside out. Dbisqlc has been out of active development for so long that nobody knows it inside out any more. I can imagine that dbisql was originally written to closely mimic dbisqlc but it may have diverged since then. Nobody has maintained an active comparison of the two applications.

Here are a few general things that come to mind:

For the most part, query processing is done on the engine side so differences in that regard should be rare.

• The two apps use different client interfaces and therefore might get slightly options set or use different types of cursors
• dbisql is a unicode app, dbisqlc is not
• The two apps might fetch or cache rows differently as you scroll through a result set

If you have a specific difference you want to more about, I can look into it.

[VolkerBarth · Accepted solution]

Thanks for that explanation, and I do appreciate that there won't be a full answer. - I'm really only asking w.r.t. the part of query processing that is done on the client. One such difference I noticed last week is the syntax error produced by an enclosed EXCEPT statement in dbisqlc - something that is valid for DBISQL (see the link in my question). Naively I like to think that all query processing is done on the server but that seems an over-simplification.

Besides that, I remember to have come accross such topics now and then. I still do use dbisqlc more often than DBISQL, and sometimes I'm stuck with syntax errors that turn out to be dbisqlc-specific - which usually comes as a surprise... But I can't remember particular symptoms currently (and I guess I will already have asked in the newsgroups at that time).

So no need to explore further, John:)

[johnsmirnios · Accepted solution]

Certainly, dbisql and dbisqlc have completely different grammars for the statements they recognize. Heh... did you know dbisqlc has a "deduce primary key for table_name" statement that automatically adds a primary key using all non-null and non-long columns? Not useful, not advertised but it's there 🙂

The problem with dbisqlc recognizing the statement that started with parentheses is a problem with its own grammar. That could have been an oversight or perhaps the database server didn't support statements that started with parentheses at the time.

[VolkerBarth · Accepted solution]

Well, I guess I've been still expecting dbisqlc to be as much adapted to the appropriate version that it will support the full syntax - and have thought that the "no more actively developped" fact is primarily focussed on leaving the GUI features etc. unchanged.

So I'm learning now that the "deprecated" status will also mean that newer syntax elements may or may not be supported in dbisqlc. "Use at your own risk", they say. That's no critism at all, just a personal learning experience...