 | |
Re: ClassCastException when querying AS2000 using ADOMD 9.0
microsoft.public.sqlserver.olap microsoft.public.sqlserver.olap
 |
| | Thread Tools | Display Modes |
#1
 
| |||
| |||
|
Re: ClassCastException when querying AS2000 using ADOMD 9.0 -
06-09-2006
, 07:26 PM
|
Hello, I have a client app that needs to connect to both AS2000 and AS2005. Connecting to AS2005 works fine, but I have the following problem connecting to AS2000. If I run a query (in this case GetSchemaDataSet()) on a thread other than the one that opened the connection I get the following exception: Unable to cast COM object of type 'Microsoft.AnalysisServices.AdomdClient.XASC' to interface type 'Microsoft.AnalysisServices.AdomdClient.IXASC'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{33B2B132-69BE-4ADE-A90E-939972B93FD5}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)). This does NOT happen connecting to AS2005, I assume because no casting is needed since the client library (ADOMD 9.0) and the server are of the same type and generation. Also, this didn't happen when I was using the old Interop.ADOMD libraries to connect to AS2000 from .NET. If I check the connection in the thread its state is always "Open" as I would expect, and all other properties I can inspect are the same whether or not I open the connection inside or outside of the worker thread. But clearly something is happening. Does anyone have any information about this, how to work around it, etc.? I've not done a lot of multi-threaded code, so perhaps I'm missing something. But I don't want to keep closing and opening a connection on each thread, nor do I want separate code paths for AS2000 and 2005. I've attached some source that illustrates this issue (VS2005); the server name will need to be changed. Thanks in advance for suggestions, code snips, design recommendations... Keith |
#2
| |||
| |||
|
|
This sounds like a setup issue -- either MSXML6 isn't installed, or the msadomdx.dll isn't properly registered... The reason I say this is because ADOMD.NET is able to communicate natively with AS 2005. But to communicate with AS 2000, it uses a COM component called IXMLA (implemented in msadomdx.dll). And it appears that something isn't working properly there... I would suggest verifying that MSXML6 is installed properly (it is required by msadomdx.dll) and if necessary re-register msadomdx.dll. HTH, Akshai |
Thanks for the reply. I checked on MSXML 6, and it is installed; I even did
a "Repair" on it AND registered msadomdx.dll just to be sure. There was no
change in the behavior.
Since synchronous queries succeed it didn't seem like the XML parser was a
likely culprit, but you never know.
The server I'm connecting to is 2003 Server with both SQL2000 and SQL2005
installed. 2000 is installed as <machinename>, and 2005 as
<machinename>/<instancename>.
I thought the problem might the my dev machine (XP SP2, also with a SQL2005
instance & PTS but no 2000, same problems), but I ran my test app locally on
the remote server with the same result.
Do you have any other insights or suggestions? This is a big issue for me.
Thanks!
#3
| |||
| |||
|
|
"Akshai Mirchandani [MS]" <akshaim (AT) online (DOT) microsoft.com> wrote in message news:uS7ICSCjGHA.4776 (AT) TK2MSFTNGP05 (DOT) phx.gbl... This sounds like a setup issue -- either MSXML6 isn't installed, or the msadomdx.dll isn't properly registered... The reason I say this is because ADOMD.NET is able to communicate natively with AS 2005. But to communicate with AS 2000, it uses a COM component called IXMLA (implemented in msadomdx.dll). And it appears that something isn't working properly there... I would suggest verifying that MSXML6 is installed properly (it is required by msadomdx.dll) and if necessary re-register msadomdx.dll. HTH, Akshai Akshai, Thanks for the reply. I checked on MSXML 6, and it is installed; I even did a "Repair" on it AND registered msadomdx.dll just to be sure. There was no change in the behavior. Since synchronous queries succeed it didn't seem like the XML parser was a likely culprit, but you never know. The server I'm connecting to is 2003 Server with both SQL2000 and SQL2005 installed. 2000 is installed as <machinename>, and 2005 as machinename>/<instancename>. I thought the problem might the my dev machine (XP SP2, also with a SQL2005 instance & PTS but no 2000, same problems), but I ran my test app locally on the remote server with the same result. Do you have any other insights or suggestions? This is a big issue for me. Thanks! |
#4
| |||
| |||
|
|
Ah, I just noticed the part where you say you are accessing the object on another thread. I believe the problem here is with the COM threading model. I can't say for sure what the issue is, but you may want to check how your application is initializing COM... Thanks, Akshai |
I'm not sure where to start on your suggestion. I'm not (AFAIK)
initializing COM directly, only via calling functions in the .NET/ADOMD.NET
libraries. I'm sure there is some interop stuff in there, but I'm not
calling an COM interfaces directly, nor do I have any of my own interop
assemblies or RCW's.
If you take a look at the sample code I attached to my first post, you can
see it doesn't take much to produce this error, and the code is very
straight-forward. I've looked through the project and build settings but I
don't see much regarding handling COM interactions.
Could you give me an idea of where I might look?
Keith
#5
| |||
| |||
|
|
libraries. I'm sure there is some interop stuff in there, but I'm not calling an COM interfaces directly, nor do I have any of my own interop assemblies or RCW's. |
ADOMD.NET to the IXMLA component -- but is being done in the context of your
Main thread (which is currently marked as STA).
Thanks,
Akshai
--
Try out the MSDN Forums for Analysis Services at:
http://forums.microsoft.com/MSDN/Sho...ID=83&SiteID=1
This posting is provided "AS IS" with no warranties, and confers no rights
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
"Keith" <keith (AT) alh (DOT) com> wrote
Quote:
|
"Akshai Mirchandani [MS]" <akshaim (AT) online (DOT) microsoft.com> wrote in message news:Ok1wSmljGHA.3440 (AT) TK2MSFTNGP02 (DOT) phx.gbl... Ah, I just noticed the part where you say you are accessing the object on another thread. I believe the problem here is with the COM threading model. I can't say for sure what the issue is, but you may want to check how your application is initializing COM... Thanks, Akshai Akshai, I'm not sure where to start on your suggestion. I'm not (AFAIK) initializing COM directly, only via calling functions in the .NET/ADOMD.NET libraries. I'm sure there is some interop stuff in there, but I'm not calling an COM interfaces directly, nor do I have any of my own interop assemblies or RCW's. If you take a look at the sample code I attached to my first post, you can see it doesn't take much to produce this error, and the code is very straight-forward. I've looked through the project and build settings but I don't see much regarding handling COM interactions. Could you give me an idea of where I might look? Keith |
#6
| |||
| |||
|
|
Well, if you just change the [STAThread] attribute in Program.cs to [MTAThread] then the app works. But frankly I'm no .NET expert so I can't explain to you the repercussions of making such a change  In fact, there is apparently a fxcop rule that says that Forms assemblies must use STA so probably the simple solution isn't the correct one. You could also create a separate MTA thread just to initialize and create the ADOMD.NET connection -- I tried this out and it works as well. But you may be better off confirming on the .NET newsgroups what is the best way of doing this... libraries. I'm sure there is some interop stuff in there, but I'm not calling an COM interfaces directly, nor do I have any of my own interop assemblies or RCW's. As I indicated in my earlier posting, the COM interation is being done by ADOMD.NET to the IXMLA component -- but is being done in the context of your Main thread (which is currently marked as STA). Thanks, Akshai -- Try out the MSDN Forums for Analysis Services at: http://forums.microsoft.com/MSDN/Sho...ID=83&SiteID=1 This posting is provided "AS IS" with no warranties, and confers no rights Please do not send email directly to this alias. This alias is for newsgroup purposes only. "Keith" <keith (AT) alh (DOT) com> wrote in message news:ekcLD6njGHA.3496 (AT) TK2MSFTNGP02 (DOT) phx.gbl... "Akshai Mirchandani [MS]" <akshaim (AT) online (DOT) microsoft.com> wrote in message news:Ok1wSmljGHA.3440 (AT) TK2MSFTNGP02 (DOT) phx.gbl... Ah, I just noticed the part where you say you are accessing the object on another thread. I believe the problem here is with the COM threading model. I can't say for sure what the issue is, but you may want to check how your application is initializing COM... Thanks, Akshai Akshai, I'm not sure where to start on your suggestion. I'm not (AFAIK) initializing COM directly, only via calling functions in the .NET/ADOMD.NET libraries. I'm sure there is some interop stuff in there, but I'm not calling an COM interfaces directly, nor do I have any of my own interop assemblies or RCW's. If you take a look at the sample code I attached to my first post, you can see it doesn't take much to produce this error, and the code is very straight-forward. I've looked through the project and build settings but I don't see much regarding handling COM interactions. Could you give me an idea of where I might look? Keith |
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.