SQLDMO

[warlord]

I'm playing with the SQLDMO Interop to try to create an SQL database on a
server (sql 2000/2005) without as little user interaction as possible.
Logon, password and server name is about all I need.

Which I have got to work just fine and dandy - so long as the client running
it has SQL client or server installed.

How do I determine if SQLDMO is even available before I try to make any
calls to SQLDMO functions? Do I just search for a file or registry entry?
Any other suggestions?

W

 

[Michael Nemtsev]

Hello warlord,

Check for the existed sqldmo.dll ?!

w> I'm playing with the SQLDMO Interop to try to create an SQL database
w> on a server (sql 2000/2005) without as little user interaction as
w> possible. Logon, password and server name is about all I need.
w>
w> Which I have got to work just fine and dandy - so long as the client
w> running it has SQL client or server installed.
w>
w> How do I determine if SQLDMO is even available before I try to make
w> any calls to SQLDMO functions? Do I just search for a file or
w> registry entry? Any other suggestions?
w>
w> W
w>
---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsch

 

[warlord]

That's kinda what I figured - just wondered if there was a more elegant way.

 

[Nicholas Paldino [.NET/C# MVP]]

This isn't the way to do it, since you can have the DLL on the machine,
and it might not be registered correctly.

Moreover, you can't determine where it is installed, or if that dll is
the one that is registered on the system.

To the OP, I assume that you are distributing your interop assembly with
your app. What I would do is try and create an instance of the class, and
wrap it in a try/catch statement, catching the exception that is thrown when
a COM class instance can not be created.

Hope this helps.

 

[John B]

I'm playing with the SQLDMO Interop to try to create an SQL database on a
server (sql 2000/2005) without as little user interaction as possible.
Logon, password and server name is about all I need.

Which I have got to work just fine and dandy - so long as the client running
it has SQL client or server installed.

How do I determine if SQLDMO is even available before I try to make any
calls to SQLDMO functions? Do I just search for a file or registry entry?
Any other suggestions?

W

Why not just use the CREATE DATABASE DbName statement instead?

Just curious.

JB

 

[Michael Nemtsev]

Hello Nicholas Paldino [.NET/C# MVP],

N> This isn't the way to do it, since you can have the DLL on the
N> machine, and it might not be registered correctly.
N>
N> Moreover, you can't determine where it is installed, or if that
N> dll is the one that is registered on the system.
N>
N> To the OP, I assume that you are distributing your interop
N> assembly with your app. What I would do is try and create an
N> instance of the class, and wrap it in a try/catch statement, catching
N> the exception that is thrown when a COM class instance can not be
N> created.

Yep, sure. I was more pointed to the "if SQLDMO is *even available*" phrase,
but exactly try/catch is always only the good way to check that smth exists

---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

 

[warlord]

Why not just use the CREATE DATABASE DbName statement instead?

Just curious.

JB

I could do that but when you get into passing scripts to the server I find
you're not as in control of the process. You get into the whole success or
failure thing having to validate it got created not just that the script ran
successfully.

W

 

[warlord]

Hello Nicholas Paldino [.NET/C# MVP],

N> This isn't the way to do it, since you can have the DLL on the
N> machine, and it might not be registered correctly.
N> N> Moreover, you can't determine where it is installed, or if that
N> dll is the one that is registered on the system.
N> N> To the OP, I assume that you are distributing your interop
N> assembly with your app. What I would do is try and create an
N> instance of the class, and wrap it in a try/catch statement, catching
N> the exception that is thrown when a COM class instance can not be
N> created.

Yep, sure. I was more pointed to the "if SQLDMO is *even available*"
phrase, but exactly try/catch is always only the good way to check that
smth exists

I figured I'd try the try/catch to pick up on that but instead my little
test app didn't do anything but hang... I still got a few things to test in
it but if try/catch is the more elegant option I'll use it.

W