establishing cause of access violation?

[Guest]

Hi
I have a mixed managed/unmanaged project which thanks to you guys I've
managed to get rid of the linker errors of, so cheers for that.
But now I'm experiencing an unknown access violation.
Firstly this is an extended stored procedure DLL, I've been able to debug it
successfully by starting SQL server with the -c switch and when it is called
via osql then it breaks into the debugger. Fine. I'm happy with that....
However the project also has a .cpp file that is compiled with /clr. This
contains one managed function, which instantiates a C# class in a separate
assembly. The accessor function is called by the main (unmanaged) .cpp file
that is the entry point of the extended stored procedure. When I press F11 or
F10 on the accessor function, I get 'SQL server generated an access
violation, and is terminating process 51'.
This function used to be OK. I've got the debugger set to 'mixed', but it
won't step into the managed function.
Any idea how I can trace what's actually going on?

 

[Guest]

(Sorry for posting twice)

More info:
When I remove the code to access the C# class, the problem disappears. But
it still won't let me step into any of the function when the C# class is used.
The c# class works fine from a console application, and its DLL is copied to
SQL server's directory along with the xp_ DLL.
I'm not trying to debug the C# class. Just the function that instantiates it.

Are there any special considerations when calling a c# class from managed
C++, in a project that is primarily an unmanaged DLL?

Thanks

 

[Dan Guzman]

See http://support.microsoft.com/default.aspx?scid=kb;en-us;322884. CLR
integration will be included in SQL Server 2005.

 

[Guest]

I get KB article is not available.
FYI, I haven't got SQL server 2005, so please don't suggest solutions
involving that.

 

[Dan Guzman]

You might try a Knowledge base search for article 322884. I am not
suggesting that you use SQL 2005 since it is currently in beta and has not
yet been released. I am suggest you use an alternate method (e.g. unmanaged
code) if you need to implement this under SQL 2000.

Below is the relevant info from the article.
..
<Excerpt>
Microsoft does not support the use of Microsoft Common Language Runtime
(included with .NET Framework) for any COM Callable Wrapper or Managed
Extensions for C++ in either Microsoft SQL Server 7.0 or Microsoft SQL
Server 2000. This limitation for support pertains directly to the use of
extended stored procedures and the use of OLE Automation for any loading of
the libraries that you must load to run in the SQL Server memory space.
</Excerpt>

 

[Guest]

Dan - the third party company that produce the DLL have explained the
problem. Apparently since the DLL is dongled, it doesn't allow C++ - style
debugging. I tried it in release mode and it works perfectly.

But I think your point about not using managed code in SQL server's process
is worth consideration - how much of a risk do you think it is?

 

[Dan Guzman]

I'd be wary of deploying this configuration in a production environment.
Since it's unsupported, you are on your own should you run into problems.
If you feel you must go down this road, you can mitigate the risk with sound
memory management, avoiding fiber-mode and TLS, and thorough testing.

 

[Guest]

OK. We don't go for Microsoft support anyway, but I don't feel I must as I've
discovered the ATL OLEDB consumer seems remarkably easy to use.