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
"Alastair Cameron" <alastair...@blueyonder.co.uk> wrote in message
news:uW7Woq1uAHA.1836@tkmsftngp03...
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...
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" <dennis....@acadia-ins.com> wrote in message
news:eM5XPgSvAHA.2020@tkmsftngp04...
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