Philip,
When AS 2000 says it "supports" SQL Server, Access & Oracle, it means it
will understand the constraints, data types and relational logic in these
OLE DB data sources. It detects that the data source is one of these and
issues queries that are specific to the data source. This support is tested
and tuned specifically against these datasources. We can also use any ODBC
source (using a system DSN) through the OLE DB for ODBC provider, but with
lesser luck using the AS wizards and no chance of doing writebacks or other
cool stuff. Another option in your type of scenario would be to build a
driver which complies with the OLAP section of the OLE DB 2.6 spec, which
then can be used as a data source for a linked cube in AS.

Jon Jahren

"Phillip Ratzloff" <phil.ratzloff (AT) sas (DOT) com> wrote

On Fri, 8 Aug 2003 09:10:20 +0200, "Jon Jahren"
<nospam_jon (AT) softscenario (DOT) no> wrote:

Writing to the OLEDB 2.6 spec is means that I would need to support
inserting and updating of the data source, which I don't believe is a
requirement for AS. My goal is just to provide a minimal provider
that will supply AS with the data it needs. There will not be any
other consumer of this component.

I've run into two properties that were not supplied by the provider
templates: DBPROP_CURRENTCATALOG and DBPROP_SESS_AUTOCOMMITISOLEVELS.
AS was nice enough to return an error when these weren't supported by
my provider, but then I'm afraid of the cases where it returns a
general error that doesn't give me enough clues as to what's wrong.

I've spent some time to find a document titled "OLE DB Leveling:
Choosing the Right Interfaces", which identifies different levels of
conformance (e.g. interface support on each of the provider objects).
I'd hoped this might give me some clues as to additional functionality
I need to implement, but it doesn't appear to be available any more.