[Mono-list] SQL Parser for System.Data

Rodrigo Moya rodrigo@ximian.com
11 May 2002 16:47:17 +0200

On Sat, 2002-05-11 at 15:31, Piers Haken wrote:
> 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.
yes, MS SQL does it, and thus System.Data has a lot of MSSQLisms. But
not all managed providers will support the same. That's why we'd need a
SQL parser.

> 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.
we are not talking about doing the parsing on the clients, but on the
managed providers, as an internal implementation detail. That is, the
whateverSQL provider can't send SQL commands with parameter placeholders
because the DB server does not support it. So, internally, the
whateverSQL provider parses the SQL command, finds placeholders,
replaces them with values, and send the clean SQL to the DB server.

In fact, that SQL parser could even be an internal class to be used only
in System.Data managed providers.