OCI Fetch and Dynamically Allocated Local Variables

From: Jason Lee <jlee_at_rri-medtech.com>
Date: Tue, 21 Mar 2000 16:53:06 GMT
Message-ID: <38d7a8b3.63926070_at_news.ionet.net>



[Quoted] Here at the office, we've encapsulated DB connectivity in a class called clsDatabase. From this base class, we have derived clsODBCDatabase. I'm currently in the process of writing clsOCIDatabase, and I've hit a couple of snags. Using ODBC, to get data back from a query, one simply has to call SQLFetch(), then repeatedly call SQLGetData() to return a column from the row. This pretty simple and straight forward, but, as far as I know, there is not a similar method in OCI. As best as I can tell, once the query had been prepared/executed, OCIDefineByPos() must be called to bind a column from the query to a storage area in the calling code. If the column types and number were known at design time, this would not be an issue, but these classes are set up to access any table (or resultset). The number, name, type, etc. of the columns are determined at run-time by querying the DB abstraction layer (ODBC or OCI). The problem that currently stops me is how to dynamically allocate the local variables for the fetch statement. I am successfully preping/execing the SELECT and getting column names and types, but I have not yet been able to fiugre out how to create a dynamically sized list of local column variables of a disparate type (like vector<void *>). Does anyone have any pointers or working code that might help with this? Am I going about fetching the wrong way? If there is something like OCIGetData(), my life would be much easier, but I can't seem to find one, and the Oracle documentation is not that helpful (and very much overpriced. Had I known the book was what was [Quoted] [Quoted] on the CD, I wouldn't have paid $95 for it. Thanks, Larry). Any help would be greatly appreciated...

Jason Lee | Failure is not an option. It comes bundled with every Programmer/Analyst | Microsoft product. - gaudior (/. reader) Received on Tue Mar 21 2000 - 17:53:06 CET

Original text of this message