Diego Gonzalez

.NET, movies & //TODO:

JDBC-like SQL for ADO.NET

I was working for Patterns & Practices group on the development of some Application Blocks (User Interface Process, Configuration Management, Application Updater), after that they told me to develop a completly new version for the DAAB where every mehtod of the DAAB uses only ADO.NET interfaces. It will be available online on the following Workspace this week... i hope.
But it have some limitations for example the SQL syntax, you can't use any ADO.NET provider using the same SQL syntax. I was wondering if it's possible to develop an abstraction over ADO.NET drivers so the client application can issue a generic SQL and then this SQL is converted to the specific SQL supported by the ADO.NET drivers. It's the same approach used by JDBC... what is needed to implement this?
  • A generic SQL grammar (scanner and parser). Which receives an SQL which is ADO.NET SQL and creates an AST representation.
  • A converter which takes the AST and generates an SQL statement for a specific ADO.NET provider.
.... does anybody have a sample SQL grammar for LEX/YACC or perhaps Coco/R? I was writing my own grammar to test my idea using Grammatica.... but my DiegoSQL grammar wont be correct. :)
Posted: Aug 11 2003, 12:12 PM by DiegoGonzalez | with 3 comment(s)
Filed under:

Comments

Slavomir Furman said:

Hello!

For some examples of SQL in BNF (Backus-Naur Form notation), for example SQL92, PL/SQL, etc. You may find this at:

http://cui.unige.ch/isi/bnf/

As for T-SQL, unfortunattely it seems that it is not easy to produce context-free grammar to it (some also says that this is not possible). There is good discussion about thsi at:

http://dbforums.com/t405140.html

In case yo find something more real, then let us know.

thanks,
Slavo.
# August 11, 2003 10:38 AM

Andres Aguiar said:

What do you want to do with the SQL statement? Just changing the parameter markers (i.e., ? for @ParameterName) or dealing with other SQL differences like outer joins?

# August 11, 2003 11:47 AM

Diego Gonzalez said:

You can solve both issues with this, because the complete Statement tree is available to process and any conversion could be done... of course you wont be able to convert PL/SQL in to T/SQL. I was thinking about supporting SQL92, which is very limited (compared with PL/SQL or T/SQL).

Anyway using this will considerably down performance on the client side because the SQL must be parsed and converted... of course a Passthrough option could be available.
# August 11, 2003 1:10 PM
Leave a Comment

(required) 

(required) 

(optional)

(required)