There are a lot of benefits to named parameters and users seem to like them - it would be a shame to see them go.
How complex would a parser be? Wouldn't it just need to handle the distinction between string values/comments etc. and SQL text? That would be a lot simpler than parsing the actual SQL. What does EJB3 do for native queries? Can we do something like that (or better)? -- Jeremy On 6/13/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
DAS has a problem with its attempt to support named parameters in SQL as in: command = Factory.createCommand ("select * from Customer where Customer.id = :id") command.setParm("id", 500); We have been using a colon as the parameter marker and this works well since we can do a simple scan of the select statement to find the named parameter markers and replace them with '?'. Unfortunately, a scan is not sufficient when the SQL uses colons as part of the statement itself, like in an embedded timestamp. To pluck out the parameter markers in these more complicated cases requires a parser and, IMO, the DAS has no business parsing SQL. So, what I propose is to remove support for named parameters altogether and leave clients with indexed parameter access like this: command = Factory.createCommand ("select * from Customer where Customer.id = ?") command.setParm(1, 500); Any opinions? Thanks, --Kevin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]