Re: OLE DB Templates rules

"Beauchemin, Bob" <[email protected]> Fri, 2 Aug 2002 08:59:15 -0700
Newsgroups gmane.comp.windows.devel.oledb.devel
Message-ID <94FD4438D783D74EA86DC692E776C127016061A4@la-infoserver.develop.com>
OLE DB is a specification for abstracting data access. It does not attempt to abstract away the difference between data stores. Therefore, in some cases, there are no rules but a set of possible behaviors and a way for the provider to indicate the behavior(s) it supports.
 
WRT the rules you are wanting, these differ among providers. When using SQL Server, output parameters can only be returned when rowsets have been released. In Oracle (using Oracle's provider, but not using MSDAORA provider from Microsoft), this is not the case; you can get output parameters before rowset pointers (actually pointers to refcursors) have been released. The property that tell you the behavior of the provider is in DBPROPSET_DATASOURCEINFO (IIRC) and is named DBPROP_OUTPUTPARAMETERAVAILABILITY. It is a set of bitswitches that you can query to find out when output parameters are available.
 
WRT providers returning the number of rows affected from a SELECT statement, this varies not only among providers, but within the same provider. Although Access will return a real value (last I looked), SQL Server only returns the number of rows for KEYSET and STATIC server cursors (the cursor you get is defined by DBPROPSET_ROWSET properties). When you use cursorless mode (the default) then rows affected return -1 on a SELECT. This is the provider's way of telling you that information is unavailable. 
 
The way to do the right thing every time is to query the appropriate properties or information from the provider (this info is sometimes in the provider-specific docs as well) then use the appropriate behaviors. A la QueryInterface in COM. If you QI for an interface and get back NULL, that indicates that the provider does not support that interface (OLE DB consists of required and optional interfaces) which means that the data source (database) does not support that behavior (or you have forgotten to specify the needed properties to request the behavior).
 
The point is to allow providers to expose as much rich functionality as their database permits, rather than a lowest common denominator approach.
 
Hope this helps clear things up,
Bob Beauchemin
http://staff.develop.com/bobb
 

-----Original Message-----
From: Frederic Gos [mailto:[email protected]]
Sent: Friday, August 02, 2002 7:13 AM
To: [email protected]
Subject: [OLEDB_DEV] OLE DB Templates rules



Hi, 

I'n trying to get the rules straight when using teh OLE DB templates of VC7. 

Depending on how you wrote the sp's, the order og the tempalte functions 
you must call change. As an example, if you have an SP with output params 
that also retuns a rowset, you have to call close before getting access to the 
params. 

The question is: Is there a summary of these rules? Are they consistent? 

What I'm trying to do is to write code that will do the right thing everytime, no matter 
how the sp was written. The only assumption would be that all metadata is known at compile 
time. No Dynamic or Manual accessors.  

Is that naive? 
Do I even make sense? :-) 

cheers 
Frederic 

You can read messages from the OLEDB_DEV archive, unsubscribe from OLEDB_DEV, or subscribe to other DevelopMentor lists at http://discuss.develop.com. 


You can read messages from the OLEDB_DEV archive, unsubscribe from OLEDB_DEV,
or subscribe to other DevelopMentor lists at http://discuss.develop.com.