When you add an extended stored procedure, you point it to the dll, which should be stored in the Binn folder on the C drive. In a clustered environment, you don't have access to the C drive from with the dialog in SQL Server, I'm guessing because if the cluster fails, the C drive is no longer the C drive but the C drive of the other cluster node.
For now I put the dll on a shared drive, so we can test, but I want to be able to put the dll on the OS drive. I know I'll have to put a copy of the dll on both cluster nodes, so that's not the issue.
My question is if it is possible to register the dll on both cluster nodes and leave the whole path out of the extended stored procedure. I'd like to hear how others have solved this.
0
Comments
I would keep the DLL in c drives in both clusters.
You just need to register it twice in both clusters.
Think of them as two separate sql servers.
Independent Consultant/Developer
blog: https://dynamicsuser.net/nav/b/ara3n
I've done this 3 times now and it works perfectly.
Independent Consultant/Developer
blog: https://dynamicsuser.net/nav/b/ara3n
So if I register the dll on both clusters I can just leave out the path and type "xp_ndo.dll" without the path?
RIS Plus, LLC
I put the dll in the bin directory.
Then I connect in enterprise manger, I paste this code.
If the there is an error when I execute this, I drop the procedures that exists.
I do this on both clusters.
Independent Consultant/Developer
blog: https://dynamicsuser.net/nav/b/ara3n
Thanks Ahmed
RIS Plus, LLC
When I'm onsite, I am sometimes the same way, there is too many distraction and things going on.
Independent Consultant/Developer
blog: https://dynamicsuser.net/nav/b/ara3n
The extended stored procedure itself was present on both clusters as soon as I added it to the first cluster. All you have to do is add the dll to the second cluster.
RIS Plus, LLC
I was connecting to each actual servers.
Independent Consultant/Developer
blog: https://dynamicsuser.net/nav/b/ara3n
RIS Plus, LLC