Re: DBI prepare_cached and DBD::Sybase

I really understand [the need for prepare_cached()], and I can see that an application would want to use it, but Sybase's support of placeholders is (maybe) somewhat limited in this respect.

Sometimes abstractions work great in theory, but suck for some edge cases. Trying to pretend that all databases support placeholders makes code much more portable, at the expense of suboptimal (or just plain terrible) performance when dealing with a database that doesn't support placeholders. Sybase, at least through the native DB*Lib API, doesn't support placeholders (I think this is true through CT*Lib, though that's years back, and I don't have that API at hand). To cope with this, the various abstract APIs (e.g., DBI, ODBC) that sit atop the native API have to pretend to prepare a query while in reality they're expanding the query and quoting bind variables at execute time.

Comment on Re: DBI prepare_cached and DBD::Sybase

Replies are listed 'Best First'.
Re: Re: DBI prepare_cached and DBD::Sybase by mpeppler (Vicar) on May 20, 2002 at 20:39 UTC
The CTlib API supports placeholders (and I've even added that support to Sybase::CTlib). But the support is in the server - this means that some code examples given in the DBI man page fail miserably. In particular, perldoc DBI mentions that to include NULL values from placeholders in a WHERE clause you need to do something like this: `... WHERE (product_code = ? OR (? IS NULL AND product_code IS NULL))` [download] This will fail miserably with Sybase, because Sybase will attempt to find the datatype of each placeholder by matching it with a column. The `? is null` doesn't map to any column name, so Sybase returns an error. Whether this is a behavior that is valid or not is maybe debatable, but the great advantage is that Sybase knows the datatype of each placeholder when you execute a prepared statement - no need to bind them with a specific datatype (and in fact using bind_param() with a datatype will ignore the hint). Cross-platform APIs are non-trivial, and cross-platform programming with databases is even more so because various forms of SQL syntax can have a huge impact on performance. Michael	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Re: DBI prepare_cached and DBD::Sybase
by mpeppler (Vicar) on May 20, 2002 at 20:39 UTC

But the support is in the server - this means that some code examples given in the DBI man page fail miserably. In particular, perldoc DBI mentions that to include NULL values from placeholders in a WHERE clause you need to do something like this:

... WHERE (product_code = ? OR (? IS NULL AND product_code IS NULL))
[download]

? is null

Whether this is a behavior that is valid or not is maybe debatable, but the great advantage is that Sybase knows the datatype of each placeholder when you execute a prepared statement - no need to bind them with a specific datatype (and in fact using bind_param() with a datatype will ignore the hint).

Cross-platform APIs are non-trivial, and cross-platform programming with databases is even more so because various forms of SQL syntax can have a huge impact on performance.

Michael

[reply]
[d/l]
[select]