[Mono-list] SQL Parser for System.Data

[Piers Haken]

But this breaks the whole idea of prepared statements: where you prepare
a statement in the database and then bind the parameters to it on each
call.

I don't know about other databases but I know that for MS SQL, there's a
significant performance gain in preparing a statement and then calling
it multiple times, as opposed to just calling an ad-hoc statement
multiple times. As far as I know it's essentially creating a stored
procedure out of the statement.

If you do the parameter replacement on the client side then you lose all
this benefit. The whole idea of SqlParameter is that the parameter
replacement is done by the DBMS.

Piers.

-----Original Message-----
From: Rodrigo Moya [mailto:rodrigo@ximian.com] 
Sent: Saturday, May 11, 2002 5:20 AM
To: Piers Haken
Cc: Daniel Morgan; Mono List
Subject: RE: [Mono-list] SQL Parser for System.Data


On Sat, 2002-05-11 at 12:16, Piers Haken wrote:
> I thought that support for parameters was supplied by the underlying 
> data layer?
> 
> For example, in ADO, when you get the parameters for a query, it send 
> the query to the database and which parses it and the sends back a 
> list of types parameters which the client fills in before making the 
> call.
> 
> I don't think you need to be doing any SQL parsing in the System.Data 
> classes unless the particular data layer that you're providing a 
> connector for doesn't support this feature - but OLEDB & ADO (and 
> JDBC, I think) don't require this.
> 
hmm, well, we may need it, since I suppose client applications will use
a generic format for specifying parameters into the SQL command (Oracle
uses :parameter, while others may use something different). So, I think
we should have a generic SQL parser which understands that generic
notation for parameters, and thus any provider can parse the SQL sent by
clients, replace the parameters with the correct values, and execute the
SQL command on the server (or just pass the string as-is for the DB
server to process it, if it can).

So, yes, I think we'll need a very basic SQL parser that understands the
basic commands.

cheers