Embedded SQL in C#

  • Thread starter Thread starter VictorReinhart
  • Start date Start date
<<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?
 
VictorReinhart said:
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?
Click to expand...

I unit test mine with DbUnit and JUnit. That way they're still
automated, unlike cutting and pasting with SQL*Plus...
 
<<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
 
VictorReinhart said:
<<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.
Click to expand...

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.
 
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...
 
Seems like the solution is to use PowerBuilder if it provides the
functionality you want/need.
 
Back
Top