By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,836 Members | 1,735 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,836 IT Pros & Developers. It's quick & easy.

establishing cause of access violation?

P: n/a
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?

Nov 17 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
(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
"Bonj" wrote:
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?

Nov 17 '05 #2

P: n/a
See http://support.microsoft.com/default...b;en-us;322884. CLR
integration will be included in SQL Server 2005.

--
Hope this helps.

Dan Guzman
SQL Server MVP

"Bonj" <Bo**@discussions.microsoft.com> wrote in message
news:EE**********************************@microsof t.com...
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?

Nov 17 '05 #3

P: n/a
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" wrote:
See http://support.microsoft.com/default...b;en-us;322884. CLR
integration will be included in SQL Server 2005.

--
Hope this helps.

Dan Guzman
SQL Server MVP

"Bonj" <Bo**@discussions.microsoft.com> wrote in message
news:EE**********************************@microsof t.com...
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?


Nov 17 '05 #4

P: n/a
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>

--
Hope this helps.

Dan Guzman
SQL Server MVP

"Bonj" <Bo**@discussions.microsoft.com> wrote in message
news:63**********************************@microsof t.com...
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" wrote:
See http://support.microsoft.com/default...b;en-us;322884. CLR
integration will be included in SQL Server 2005.

--
Hope this helps.

Dan Guzman
SQL Server MVP

"Bonj" <Bo**@discussions.microsoft.com> wrote in message
news:EE**********************************@microsof t.com...
> 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?
>
>
>


Nov 17 '05 #5

P: n/a
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?
Nov 17 '05 #6

P: n/a
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.

--
Hope this helps.

Dan Guzman
SQL Server MVP

"Bonj" <Bo**@discussions.microsoft.com> wrote in message
news:88**********************************@microsof t.com...
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?

Nov 17 '05 #7

P: n/a
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.
"Dan Guzman" wrote:
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.

--
Hope this helps.

Dan Guzman
SQL Server MVP

"Bonj" <Bo**@discussions.microsoft.com> wrote in message
news:88**********************************@microsof t.com...
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?


Nov 17 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.