Subject: RE: More on SrPersist buffers
From: Paul Steckler (steck@ccs.neu.edu)
Date: Wed Dec 05 2001 - 16:23:42 EST
In order to allocate buffers when a statement is prepared, you'd have to
- parse the SQL to know how many columns there will be
in the result set (it might be `*', meaning all columns)
- consult the database to obtain column metadata
That's possible, of course, but more than I think SrPersist should do.
It's also harder than it sounds, because drivers are allowed to accept
SQL that's arbitrarily more complex than the ODBC Minimum Grammar.
Result sets might be created with queries that are not the usual SELECT
... FROM ... boilerplate.
Another problem is that certain ODBC procedures can free statement
handles implicitly.
Yet another, perhaps bigger problem is that result sets can be
associated with statement handles without even running SQL queries. For
example, there are ODBC/SrPersist procedures called `foreign-keys' and
`column-privileges' that do just that. There are others in this
category. And for the meta-data result sets created by those
procedures, the number of columns varies by the driver used. How do you
allocate buffers when these procedures are used?
-- Paul
-----Original Message-----
From: Jonathan Edwards [mailto:edwards@intranet.com]
Sent: Wednesday, December 05, 2001 3:57 PM
To: steck@ccs.neu.edu
Subject: Re: More on SrPersist buffers
I still think you could completely encapsulate these buffers inside a
statement object (along with its handle). Have them automatically
allocated and bound when a statement is prepared, and then free them in
a statement-close function, which also unbinds them and free's the
statement handle. A GC of the statement object should close it.
This archive was generated by hypermail 2b28 : Wed Dec 05 2001 - 16:24:34 EST