Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


connections


connections

Author
Message
Kevin Terry
Kevin Terry
SSC Veteran
SSC Veteran (258 reputation)SSC Veteran (258 reputation)SSC Veteran (258 reputation)SSC Veteran (258 reputation)SSC Veteran (258 reputation)SSC Veteran (258 reputation)SSC Veteran (258 reputation)SSC Veteran (258 reputation)

Group: General Forum Members
Points: 258 Visits: 269
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?

Thanks!!

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?



Steve Jones
Steve Jones
SSC-Dedicated
SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)

Group: Administrators
Points: 36111 Visits: 18742
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
My Blog: www.voiceofthedba.com
Kevin Terry
Kevin Terry
SSC Veteran
SSC Veteran (258 reputation)SSC Veteran (258 reputation)SSC Veteran (258 reputation)SSC Veteran (258 reputation)SSC Veteran (258 reputation)SSC Veteran (258 reputation)SSC Veteran (258 reputation)SSC Veteran (258 reputation)

Group: General Forum Members
Points: 258 Visits: 269
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?



matt stockham
matt stockham
Right there with Babe
Right there with Babe (766 reputation)Right there with Babe (766 reputation)Right there with Babe (766 reputation)Right there with Babe (766 reputation)Right there with Babe (766 reputation)Right there with Babe (766 reputation)Right there with Babe (766 reputation)Right there with Babe (766 reputation)

Group: General Forum Members
Points: 766 Visits: 3178
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.
Doug S.
Doug S.
SSC-Enthusiastic
SSC-Enthusiastic (123 reputation)SSC-Enthusiastic (123 reputation)SSC-Enthusiastic (123 reputation)SSC-Enthusiastic (123 reputation)SSC-Enthusiastic (123 reputation)SSC-Enthusiastic (123 reputation)SSC-Enthusiastic (123 reputation)SSC-Enthusiastic (123 reputation)

Group: General Forum Members
Points: 123 Visits: 331
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.

Cheers



Doug
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search