January 10, 2008 at 11:48 am
We have an desktop application that uses sql server as its back end. This app was developed using dotnet framework 2.0 in C#.
Our developer is claiming that in order to use the typical sql server connection screen (has drop down box of available sql servers on top, with refresh button next to it, then log in section (integrated or sql log in, then at bottom list of databases).
This screen only appears to work (our developer is claiming) if the computer our app is installed on has sql server 2005 SMO (basically the client tools). Now that doesn't make any sense to me, but I'm more of a production dba, not a developer, so am not sure.
Does anyone have any knowledge about this?
Thanks!!
January 14, 2008 at 8:53 pm
My understanding is that SMO is used to manage the objects and SQL Server administration. It is not really a client tool.
January 15, 2008 at 7:57 am
Thanks, yeah, that's kind of what I thought. I guess my question is does it make sense that a workstation app that uses sql server as a back-end, would need to have sql client tools installed on all the workstations that are going to use this app?
My thought is if the developer (using C# and .Net 2) is using namespaces/programming objects related to SMO, shouldn't the required assemblies or whatever be built into the application? As opposed to having to install sql client tools (or just SMO if possible) on every client workstation?
January 15, 2008 at 5:05 pm
Kevin Terry (1/15/2008)
...I guess my question is does it make sense that a workstation app that uses sql server as a back-end, would need to have sql client tools installed on all the workstations that are going to use this app?My thought is if the developer (using C# and .Net 2) is using namespaces/programming objects related to SMO, shouldn't the required assemblies or whatever be built into the application?
I had to read this thread a number of times to make sure I wasn't missing something. There is no reason to install any sql server mgmt client tools on a workstation using your app. Everything will be built in to the app....
January 24, 2008 at 11:30 am
Since SMO is more than a client tool, I cannot see any point why they need it.
January 24, 2008 at 2:45 pm
I am not very familiar with SMO, but I remember I wrote an application using DMO (the ancestor of SMO) a couple of years ago with a drop down box of available sql servers. The only reason to use DMO was to capture the list of available sql servers. And the requirements were to install SQL Server client components. I can't remember which function I used but it did some kind of a broadcast over the local network to find the servers. At least with DMO it was documented to install the client components in this case. Working with SMO probably has the same requirements.
Peter
January 24, 2008 at 4:18 pm
It looks like an install of SQLServer2005_XMO.msi on the developer's pc will allow distribution of the components with the app.
(DMO did require an install of components via registering SQLDMO.dll.)
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply