Hi all,

In this post when I am referring to "Embedded SQL" I am thinking of
this http://en.wikipedia.org/wiki/Embedded_SQL. That is, a programmer
embeds his SQL statements in some host language (e.g. Java) and runs a
preprocessor which compiles the SQL before passing on the result to
the host language compiler. That is, embedded SQL do not refer to ODBC
or JDBC (in this post).

I have often wondered why embedded SQL has not become more popular
than it has. While it is popular in the mainframe world, I atleast,
have not seen much use of it outside. In stead I have seen people use
ODBC or JDBC for purposes where embedded SQL could have been used.
However, ODBC/JDBC seems mostly inferior to embedded SQL as it lacks
syntax and type checking. And in my experience, most people do
consider ODBC/JDBC cumbersome to use.

To my questions:

Am I just "in the wrong circles" when I consider embedded SQL mostly
confined to the mainframe world?

And if not, why do people think ODBC/JDBC is so much more popular than
embedded SQL?


Greetings,

Mads Lindstrøm

On 15.07.2008 22:41, Mads wrote:

Probably not.

Nowadays many seem to be using some or another form of persistence
framework (e.g. OR mapper) which hides SQL (completely) from the
application. So there is no room for embedded SQL in the application as
well as the framework, as that has to generate SQL statements typically
based on some meta data.

Then there is also the issue of compatibility: If you try to write a
multi DB application you might make your life much harder with
preprocessing since you potentially need multiple preprocessors for each
database type and consequently multiple applications. (Cross DB is a
myth most of the time anyway but in some cases it can be done). In Java
it is more common to do such distinctions at runtime which would be
harder with multiple preprocessors. There is a standard called "SQLJ"
for embedded SQL in Java which focuses on syntax and there seem to be
multiple implementations available.

I personally also would rather use plain JDBC instead of adding one more
step to a build process. Syntax and type errors should be caught during
testing anyway. And needing a preprocessor for Java code can actually
make working with an IDE harder. See also

http://en.wikipedia.org/wiki/SQLJ

Just my 0.02 EUR...

Kind regards

robert

On 15.07.2008 22:41, Mads wrote:

Probably not.

Nowadays many seem to be using some or another form of persistence
framework (e.g. OR mapper) which hides SQL (completely) from the
application. So there is no room for embedded SQL in the application as
well as the framework, as that has to generate SQL statements typically
based on some meta data.

Then there is also the issue of compatibility: If you try to write a
multi DB application you might make your life much harder with
preprocessing since you potentially need multiple preprocessors for each
database type and consequently multiple applications. (Cross DB is a
myth most of the time anyway but in some cases it can be done). In Java
it is more common to do such distinctions at runtime which would be
harder with multiple preprocessors. There is a standard called "SQLJ"
for embedded SQL in Java which focuses on syntax and there seem to be
multiple implementations available.

I personally also would rather use plain JDBC instead of adding one more
step to a build process. Syntax and type errors should be caught during
testing anyway. And needing a preprocessor for Java code can actually
make working with an IDE harder. See also

http://en.wikipedia.org/wiki/SQLJ

Just my 0.02 EUR...

Kind regards

robert

On 15.07.2008 22:41, Mads wrote:

Probably not.

Nowadays many seem to be using some or another form of persistence
framework (e.g. OR mapper) which hides SQL (completely) from the
application. So there is no room for embedded SQL in the application as
well as the framework, as that has to generate SQL statements typically
based on some meta data.

Then there is also the issue of compatibility: If you try to write a
multi DB application you might make your life much harder with
preprocessing since you potentially need multiple preprocessors for each
database type and consequently multiple applications. (Cross DB is a
myth most of the time anyway but in some cases it can be done). In Java
it is more common to do such distinctions at runtime which would be
harder with multiple preprocessors. There is a standard called "SQLJ"
for embedded SQL in Java which focuses on syntax and there seem to be
multiple implementations available.

I personally also would rather use plain JDBC instead of adding one more
step to a build process. Syntax and type errors should be caught during
testing anyway. And needing a preprocessor for Java code can actually
make working with an IDE harder. See also

http://en.wikipedia.org/wiki/SQLJ

Just my 0.02 EUR...

Kind regards

robert

The trade-offs in embedding SQL are:
1) You use only one SQL product in your package. Great if you don't
have to sell a package on multiple platforms.
2) You have only one module of source code to maintain. Major
advantage for a large package.
3) End users see only one executable, so OS and hardware can be
limited.
4) Embedded code is fast and tight since you are using the vendor API
and a generic ODBC/JDBC.

The trade-offs in embedding SQL are:
1) You use only one SQL product in your package. Great if you don't
have to sell a package on multiple platforms.
2) You have only one module of source code to maintain. Major
advantage for a large package.
3) End users see only one executable, so OS and hardware can be
limited.
4) Embedded code is fast and tight since you are using the vendor API
and a generic ODBC/JDBC.

The trade-offs in embedding SQL are:
1) You use only one SQL product in your package. Great if you don't
have to sell a package on multiple platforms.
2) You have only one module of source code to maintain. Major
advantage for a large package.
3) End users see only one executable, so OS and hardware can be
limited.
4) Embedded code is fast and tight since you are using the vendor API
and a generic ODBC/JDBC.