Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How to specify "MSOLAP" Provider (highest version) in ADO connection string?

543 views
Skip to first unread message

Alastair Cameron

unread,
Apr 2, 2001, 5:54:58 AM4/2/01
to
Hi.

I've got a VB6 application that is using PivotTable services and the MSOLAP
Provider (V8) to create a local offline .CUB file from relational data. I
have everything working, but one issue has just come up.

One of our development PCs had the V8 provider installed (via PTSLITE)
*FIRST* and then had the Office 2000 Web Components installed (which
includes the V7) provider *SECOND*.

My ADO connection string includes "PROVIDER=MSOLAP" and the V7 provider
(because it was the most recently registered?) was being used. However,
because I'm making use of member properties which the v7 provider doesn't
support, the code crashed.

My question is: We require the MSOLAP V8 provider (or higher) for the code
to work. How do I specify this generically in the ADO connection string to
say "PROVIDER=MSOLAP highest version installed on computer"??? I know I can
do things like "PROVIDER=MSOLAP.2" but wasn't sure exactly what this did...

Thanks.

Alastair

cs5...@yahoo.com

unread,
Apr 2, 2001, 9:30:28 AM4/2/01
to
provider=msolap.2 will do.

"Alastair Cameron" <alastair...@blueyonder.co.uk> wrote in message
news:uW7Woq1uAHA.1836@tkmsftngp03...

Dennis Redfield

unread,
Apr 3, 2001, 9:32:27 AM4/3/01
to
There are two issues here (Workstation Configuration and Program Logic):
1) when you have multiple MSOLAP DLLs on a machine you should unregister
the lowest DLL, unregister and re-register the higher. When you do, a call
to Provider=MSOLAP will return the MSOLAP.2 DLL.
2) The second issue is how do we know what DLL we got when we made the
Provider=MSOLAP call. The connection object has a property which shows the
device dependent name of the provider retrieved on the machine where the
program is run. thus in VB we could write something like:

If Not oADO.OpenOLAPConnection(strConnectionString, oCat) Then
MsgBox "ERROR: DSO Connection Failed!"
Exit Sub
End If
msgbox oCat.ActiveConnection.Provider

.ActiveConnection.Provider will contain the string MSOLAP.1, MSOLAP.2 or
whatever.
You can then choose to continue processing or warn the user that the machine
configuration is incorrect (see problem #1 above)

"Alastair Cameron" <alastair...@blueyonder.co.uk> wrote in message
news:uW7Woq1uAHA.1836@tkmsftngp03...

Alastair Cameron

unread,
Apr 3, 2001, 3:48:16 PM4/3/01
to
Dennis,

1)

I understand the point about DLLs registration; presumably re-running
PTS*.EXE will force the V8 provider (MSOLAP.2) to become the "default" as in
"Provider=MSOLAP", rather than manually un/re-registering components.

2)

As for the second point, this is what I'd like to do (get the provider back,
check it's name, and then bail out if it's not >= MSOLAP.2). However,
currently my ADO connection string contains everything necessary to build
the - including provider_name, location/dsn, MDX, etc. So the .Open method
makes the connection *and* CREATEs the cube.

What do I need to do in order to be able to get at the Provider property
before going ahead with the cube building? I'm used to opening ADO
connections against relational data sources like oracle or SQL Server, but
not against this particular provider. What do I do - just define a
connection string containing only "PROVIDER=MSOLAP" and use the .Open method
on an ADODB.connection object, and then look at it's Provider property?

Alastair

"Dennis Redfield" <dennis....@acadia-ins.com> wrote in message
news:#2dyZIEvAHA.1924@tkmsftngp04...

Dennis Redfield

unread,
Apr 4, 2001, 12:58:38 PM4/4/01
to
1) You could reinstall (probably should), but we have the unreg/reg trick on
a couple of servers with no problems.
2) basically yes.

"Alastair Cameron" <alastair...@blueyonder.co.uk> wrote in message
news:uF2G1aHvAHA.1836@tkmsftngp03...

Alastair Cameron

unread,
Apr 8, 2001, 3:42:41 PM4/8/01
to
Thanks Dennis.

"Dennis Redfield" <dennis....@acadia-ins.com> wrote in message

news:eM5XPgSvAHA.2020@tkmsftngp04...

Mark Cushman

unread,
May 7, 2001, 2:53:55 PM5/7/01
to
I have an intermittant connection issue when connecting to Analysis Services
cubes using ProClarity & the MDX Sample Application. Certain cubes appear
depending on the provider MSOLAP, MSOLAP.1, & MSOLAP.2. I maintain that the
last time I looked - 3 days ago - all the cubes were visible thru ProClarity
(didn't use sample app) using the default MSOLAP. Now 3 cubes appear using
MSOLAP.1 and 2 appear using MSOLAP.2. I need them all through one provider.

The only recent change is a database refresh with some db schema changes.
This db was in 2000. The OLAP dimensions were rebuilt and cubes reprocessed.
I would not think the db has anything to do with accessing AS2000. (This
happened a couple of months ago, and my colleague thinks we did a major
refresh and schema update then too.... I recreated the cubes thinking they
got corrupted.)

I am running SQL7 and SQL2000 on the same remote server; only Analysis
Services is installed.
I am running SQL2000 and AnalysisServices on my client; SQL7/OLAP Services
was removed prior to 2000 installation

I have read the threads and would like some advice....

1) why is this happening?
2) how do I unreg the old dll? And then do I reg the latest one?
2a) or should I just run PTS*.exe?
3) will all my cubes appear with the latest MSOLAP.2? (and shouldn't they
now...?)
4) how do i see which dll is there?
5) should I do this on both client and server?


Thanks,
Mark


0 new messages