Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
Log in  ::  Register  ::  Not logged in
Home       Members    Calendar    Who's On

Add to briefcase

connections Expand / Collapse
Posted Tuesday, January 15, 2008 8:04 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Yesterday @ 3:20 PM
Points: 258, Visits: 265
This is a cross posting, sorry about that, but thought I'd see if had any luck here.

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?


maybe a better way of asking the question:
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?

Post #443021
Posted Tuesday, January 15, 2008 8:40 AM



Group: Administrators
Last Login: Today @ 7:12 AM
Points: 31,284, Visits: 15,746
SQL 2K5 includes the SQL Native Client, which isn't included with the SQL 2000 tools, nor with W2K or XP. I think Vista has it, but that problem is likely that he's using the SQL Native Client, which is the way to connect moving forward, and you need to install this on other clients.

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #443064
Posted Tuesday, January 15, 2008 8:58 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Yesterday @ 3:20 PM
Points: 258, Visits: 265
Thanks for the quick reply Steve. That's sort of what we thought, but it seems even if we do install the sql native client, it doesn't work, unless we also install SMO somehow (we think by installing sql client tools - whatever it's called in sql 2005, mgmt express or something like that). We don't want to have to make every workstation have to install client tools if we can avoid it.
Shouldn't the app have the necessary assemblies built into it, if he's using smo in the application?

Post #443080
Posted Tuesday, January 22, 2008 10:42 PM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Saturday, October 18, 2014 9:34 AM
Points: 754, Visits: 3,164
It may depend on how the application is written, but for the standard connection window you can test by creating an empty file with an extension of .udl, and then opening it. I believe that this is an OS function.
Post #446236
Posted Thursday, July 8, 2010 4:39 PM


Group: General Forum Members
Last Login: Friday, November 21, 2014 12:30 PM
Points: 115, Visits: 321
Kevin, you are basically correct. Here's the way it works.

In general, there is no such thing as you "must" run xyz setup. Anyone can reverse engineer setup disks and put files, registry settings, etc in the right place. It's simply easier to use prebuilt and pretested components.

For the develper in C# or your .NET application, open the project and look at project references. These are the .NET and other DLL's required to run your application. Some of these are stored in the global assembly cache (GAC) found on the existing computer, they can come from anywhere, but usually from an installer (MSI) downloaded as part of the .NET framework or installer from another source like SQL Client tools, visual studio, or 3rd party tool.

You can install an assembly anywhere on the target PC, but common assemblies usually go in the GAC.

Once you figure out the name of the assembly they used (for example Microsoft.Sqlserver.Smo) then you can determine the best way to deploy it.

Creating a msi installer in .NET is pretty simple and the setup wizard will detect these dependencies (like the .NET framework) and add them to the setup project for you. Some are included as merge modules as part of the Visual Studio package.

Determining dependencies of dependencies can be tricky and sometimes its easier to use a tested package to get the 1 or 2 items you actually need. You can make web searches of assemblies to find out where to get installer modules, etc.

To see what .NET assemblies are installed go to C:\windows\assembly to get the name and version. If this list does not match the assemblies needed by the appliction then the application will trigger an exception when they attempt to use an object that is not installed.

Note that developers can sometimes put a copy of the assembly in the application folder, in addition to having a different version in the GAC.


Post #949652
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse