My main purpose would be to give users a uniform way to specify
oracle-mode within the current connection technology API's (i.e.
ODBC, JDBC, .NET, PHP, etc.). Specifying dialect 250 would make these
technologies load the fyracle connector, rather than the fbclient
lib. One thorny issue is that dialects can be set per statement
handle, and that I need it to be set at a higher level.

Roman's example is a bit different and actually highlights a design
problem in the 1.5.x series. Dialects exists in the SQL compiler, not
in the engine. For "dialect 3" new blr codes were introduced
("blr_add2" etc.) to get the semantics for that dialect from the
engine.

The real solution is to integrate the SQL compiler into the engine
properly, as Vulcan has done.

For 1.5.x I am stuck with hacks. As I did not want to introduce
another set of blr codes, a new bpb parameter (bpb_oracle_mode) is
passed at connection time, modifying the behaviour of the dialect 3
opcodes. The fyracle connector library automatically extends the
client's connection information block with this new parameter.

Until Fyracle is relatively feature complete (still needs SQLJ,
packages, REF cursors and collections), I am happy with it being
build on hacks around the 1.5.x code base. However, some client
facing choices should be future proof and work with a more elegant
implementation on top of FB3 as well.

Hence my request for input.

Paul


--- In Firebird-Architect@yahoogroups.com, "Roman Rokytskyy"
<rrokytskyy@a...> wrote:

> > What would be the exact purpose or you using a dialect?
>
> If I'm not mistaken, '' = NULL is evaluated in Oracle to TRUE. And
> there are many other features, like Oracle-specific join notation,
> etc. SQL dialect seems to be quite natural for Fyracle. Additionally
> JDBC driver can check the SQL dialect of the database and emulate
> Oracle JDBC driver including the interfaces, etc.
>
> Roman