Embedded SQL in C#

[VictorReinhart]

Hi,
I am intersted in trying to reduce the cost of C# development, by
reducing the number of lines of code. In my opinion, as a business
developer, the biggest opportunity to reduce the number of lines of
code is in database access.

My reality is that I use relational databases a lot. Other constructs,
such as flat files, Web Services, arrays, etc I don't use very much.

My data is stored on relational databases. I think that's pretty
common, nowadays.

I have been using ADO.NET and was wondering about the future.

Will C# support truly embedded SQL in the future? For example, in
PowerBuilder, since 1992, you could code as follows:

Long ll_count
String ls_last_name
SELECT Count(*), max(last_name) INTO :ll_count, :ls_last_name USING
TXN1;

IF TXN1.SQLCODE<>0 THEN ...

In C#, it seems to take many more lines of code to do the same thing.

Further, in PowerBuilder, the above statement works for any relational
database. All you have to do is change the connection parameters.

It seems that in C#, you have to contend with named parameters for SQL
Server and Oracle, vs. positional parameters for ODBC and OLE-DB.
Further, you have to explicitly create every single parameter in C#,
while in the example above, the parameters are created for you, using
datatypes which match the datatypes you use. That is a lot simpler.

Also, in C#, you are forced to use multiple TRY-CATCH constructs after
each SQL statement is executed. And, the exceptions which you catch
are different for different databases. That's an awful lot of code.

PowerBuilder has TRY-CATCH too, but it is generally not used for
relational database access.

And, let's talk cursors. In PowerBuilder, COBOL, and a few other
languages, such as PL*SQL, you can explicitly declare, open, fetch, and
close cursors. Wouldn't it be great if you could do that in C#?

Cursors give you low-level control. They are simple. And, if you
fetch too much data, you can stop.

In PowerBuilder and COBOL, you can even 'fetch in batches'. This means
that instead of getting one row at a time from the database, you
actually grab, say, 1000 rows at a time. Fetching in batches can
improve runtimes by 20 to 1, if your database is over a Wide-Area
Network, or by 4 to 1 if it is on a Local Area Network, in my
experience.

I think Embedded SQL makes sense because maybe, just maybe, it would
not become obsolete, as have a few other technologies (RDO, DAO, ADO,
etc).

Also, I think Embedded SQL is inherently much simpler than all the
above.

For example, a severe performance problem in a classic ASP application
was impacting one of my customers. The ASP app used ADO. I have read
many books about ADO, but not a one of them explained to me how a
"keyset" worked. It turns out that a keyset reads *all* the keys from
your SQL table, and puts them into memory. Well, when your table has 3
million rows, this becomes untenable. But then, how many people know
about this fact?

The reality is that RDO, DAO, ADO and ADO.NET all do things "behind the
scenes" which make performance tuning difficult. You have to capture
the actual SQL they send to the database first, then tune.

I don't want to need ADO to do that for me. Wouldn't you rather just
have real embedded SQL?

Opinions?

VictorReinhart

[VictorReinhart]

<<stored procedures are validated at the time of creation or change. >>
It is true that in C#, there is no validation of SQL when it is
compiled. In PowerBuilder, however, there is. You will get a compiler
warning for any embedded SQL which has a database syntax error, for
example, incorrect column or table name. This can also be turned off.
This is another advantage of embedded SQL. The same applies for stored
procedure calls.

If your C# code which calls a stored procedure has the wrong number or
type of arguments, do you get a warning at compile time?

<<Personally, I'd hate to be the one to hunt down and fix
who-knows-how-many embedded SQL statements in a large project (the size
of those to which you refer in another post), should there ever be a
need to alter the database design. >>

Well, in PowerBuilder, if you compile your application, all SQL errors
in embedded SQL show up as warnings. True, not all my SQL is embedded
-- some is dynamic and most is in datawindows, but the point is that it
is possible for the C# language to be more tightly integrated with
relational databases than it is.

In my opinion, using embedded SQL, given the syntax checking at compile
time, it would actually be much easier to maintain than to maintain
stored procedures. For example, to unit test my embedded SQL, just
copy and paste into SQL*Plus and test it. How do you test your stored
procedures?

[Jon Skeet [C# MVP]]

VictorReinhart <vi************ **@phs.com> wrote:

In my opinion, using embedded SQL, given the syntax checking at compile
time, it would actually be much easier to maintain than to maintain
stored procedures. For example, to unit test my embedded SQL, just
copy and paste into SQL*Plus and test it. How do you test your stored
procedures?

I unit test mine with DbUnit and JUnit. That way they're still
automated, unlike cutting and pasting with SQL*Plus...

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[VictorReinhart]

<<There are all sorts of database factory patterns that would enable
multiple database support>>
That is true. I looked at NHibernate, which is a factory. It looks
like it has a lot of merit but there seems to be a substantial up-front
effort to make it work, and lots of lines of code.

Embedded SQL can be verified at compile-time. Do you know of any way
to catch an SQL error at compile time in C#? An example is invalid
column name, invalid table name, or SQL syntax error.

PowerBuilder provides an option to report SQL errors at compile time.
It is extremely helpful to find an error at compile time rather than at
runtime. And, it is very nice to be able to validate all SQL in the
entire application in a compile, if desired. This compile-time error
detection, plus the easy ability to copy and paste the SQL for unit
testing, saves a lot of time when developing an application. Also, it
makes for far fewer lines of code, which are much easier to understand.

Victor Reinhart

[Jon Skeet [C# MVP]]

VictorReinhart <vi************ **@phs.com> wrote:

<<There are all sorts of database factory patterns that would enable
multiple database support>>
That is true. I looked at NHibernate, which is a factory. It looks
like it has a lot of merit but there seems to be a substantial up-front
effort to make it work, and lots of lines of code.

Embedded SQL can be verified at compile-time. Do you know of any way
to catch an SQL error at compile time in C#? An example is invalid
column name, invalid table name, or SQL syntax error.

PowerBuilder provides an option to report SQL errors at compile time.
It is extremely helpful to find an error at compile time rather than at
runtime. And, it is very nice to be able to validate all SQL in the
entire application in a compile, if desired. This compile-time error
detection, plus the easy ability to copy and paste the SQL for unit
testing, saves a lot of time when developing an application. Also, it
makes for far fewer lines of code, which are much easier to understand.

Does that mean you can only use absolutely standard SQL? What if you
want to use SQL which is T-SQL or P/L SQL specific? The language (and
the compiler) would have to have detailed knowledge of all the
databases you want to use. That sounds like a bad idea to me.

To be honest, the idea of a general-purpose *language* knowing about
SQL directly doesn't sound very nice to me - any more than I like the
idea of the language itself knowing about, say, XML or URLs.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Robbe Morris [C# MVP]]

The compilation would be caught at the stored procedure level.

Again, your design architecture preference is much different
than most developers and best practices suggest.

Your whole argument pretty much falls on deaf ears...

--
Robbe Morris - 2004/2005 Microsoft MVP C#
http://www.eggheadcafe.com/forums/merit.asp

"VictorReinhart " <vi************ **@phs.com> wrote in message
news:11******** **************@ g47g2000cwa.goo glegroups.com.. .

<<There are all sorts of database factory patterns that would enable
multiple database support>>
That is true. I looked at NHibernate, which is a factory. It looks
like it has a lot of merit but there seems to be a substantial up-front
effort to make it work, and lots of lines of code.

Embedded SQL can be verified at compile-time. Do you know of any way
to catch an SQL error at compile time in C#? An example is invalid
column name, invalid table name, or SQL syntax error.

PowerBuilder provides an option to report SQL errors at compile time.
It is extremely helpful to find an error at compile time rather than at
runtime. And, it is very nice to be able to validate all SQL in the
entire application in a compile, if desired. This compile-time error
detection, plus the easy ability to copy and paste the SQL for unit
testing, saves a lot of time when developing an application. Also, it
makes for far fewer lines of code, which are much easier to understand.

Victor Reinhart

[carion1]

Seems like the solution is to use PowerBuilder if it provides the
functionality you want/need.

--

Derek Davis
dd******@gmail. com

"VictorReinhart " <vi************ **@phs.com> wrote in message
news:11******** *************@o 13g2000cwo.goog legroups.com...

<<stored procedures are validated at the time of creation or change. >>
It is true that in C#, there is no validation of SQL when it is
compiled. In PowerBuilder, however, there is. You will get a compiler
warning for any embedded SQL which has a database syntax error, for
example, incorrect column or table name. This can also be turned off.
This is another advantage of embedded SQL. The same applies for stored
procedure calls.

If your C# code which calls a stored procedure has the wrong number or
type of arguments, do you get a warning at compile time?

<<Personally, I'd hate to be the one to hunt down and fix
who-knows-how-many embedded SQL statements in a large project (the size
of those to which you refer in another post), should there ever be a
need to alter the database design. >>

Well, in PowerBuilder, if you compile your application, all SQL errors
in embedded SQL show up as warnings. True, not all my SQL is embedded
-- some is dynamic and most is in datawindows, but the point is that it
is possible for the C# language to be more tightly integrated with
relational databases than it is.

In my opinion, using embedded SQL, given the syntax checking at compile
time, it would actually be much easier to maintain than to maintain
stored procedures. For example, to unit test my embedded SQL, just
copy and paste into SQL*Plus and test it. How do you test your stored
procedures?