If the server is using TCP/IP, then the simple way is to just telnet to the SQL Server port and see if it connects. By default, that's port 1433, so this should work:
telnet servername 1433
That will probably be appropriate in most cases.
If it's using a different port, or dynamic ports (common with a named instance), then you'll need to determine which port it's currently listening on. Check SQL Server configuration manager to see if it's a specific port, or dynamic ports. If it's using dynamic ports, then as long as you don't have multiple instances on the server, netstat -abn is probably the simplest way to find what it's using. Otherwise, dig through the Windows event log or the SQL Server error log for a message indicating which port is in use by the instance.
If SQL Server is using Named Pipes, then I believe if you're able to access shares on the machine, you have adequate network connectivity. This article says you can go further and try connecting to the IPC$ share:
http://msdn.microsoft.com/en-us/library/aa275787%28v=sql.80%29.aspx
net use \\servername\IPC$
That's written for SQL Server 2000, but I don't imagine this aspect has changed much, if at all.
The main recommendations appear to be:
If you have the install discs / files, then you should be able to install just the Client Tools.
Download SQL Server 2012 (SP1) Express (I would try the "SQL Server Management Studio Express (Tools only)" version first)
Check out: http://www.mssqltips.com/sqlservertip/1807/sql-server-2008-client-tools-installation/
If you already have a machine with OSQL installed, you might be able to copy just the following two files to the new server (place them in the same directory) and have it work:
- C:\Program Files\Microsoft SQL Server\110\Tools\Binn\OSQL.EXE
- C:\Program Files\Microsoft SQL Server\110\Tools\Binn\Resources\1033\osql.rll
As far as licensing goes, I found the following file:
C:\Program Files\Microsoft SQL Server\110\Tools\Binn\Resources\1033\license_SQLCMD.txt
That has the following snippet:
MICROSOFT SOFTWARE LICENSE TERMS MICROSOFT SQL SERVER 2012 COMMAND
LINE UTILITIES
...
1. INSTALLATION AND USE RIGHTS. You may install and use any number of copies of the software on your devices to design, develop and test
your programs.
Note:
OSQL has been superseded by SQLCMD. When you run OSQL it will display the following message:
Note: osql does not support all features of SQL Server 2012.
Use sqlcmd instead. See SQL Server Books Online for details.
However, if your existing code expects OSQL then you would need to test SQLCMD with your code first to make sure that any behavior changes between OSQL and SQLCMD do not break your code.
Best Answer
This is technically impossible, but may be sort-of implemented depending on what your threat model is. The problem is that the resulting distributable must be able to unpack/decode/decrypt the scripts such that it can submit them to SQL Server so it must contain all the required algorithms and keys.
If your threat model involves trying to stop a determined snooper (a competitor perhaps, or a black-hat looking to find holes that as-yet-unpatched installations are still vulnerable to) from seeing the code then that is impossible with a simple distributable. No matter how many layers you add they can just unpick them by analysing the distributable.
Secondly, if you make it enough hassle that they don't want to do that they have another inspection route: they could just intercept the communication with SQL Server and watch the code as it flows through. Yes TDS streams are usually encrypted, but they are running the package against their SQL server so that control both the client and the server so can control (and therefore break for their own purposes) that encryption. Thirdly, they can always just look in the database, and compare the current to a pre-patch backup if that would make the changes more obvious, the only way around this is for you to host the DB perhaps running your product in a SaaS-only manner.
If your concern is merely more opportunistic snooping, then there are many installation packagers[1] out there that support creating self-extracting executables which would run a program in the archive to run the scripts also in the archive and clean up as best as is possible afterwards, and support encrypting or otherwise obfuscating the content in transit.
[1] I'll not mention specific ones as there are many (free, Free, OpenSource, and commercial), I don't know enough about any specifically to authoritatively compare them, I know nothing of your dev and production environments (other than they include SQL Server), and anyway shopping/recommendation questions/answers are discouraged on StackExchange for reasons explained in detail elsewhere.
I would recommend against using this sort of tool for this purpose though: you are adding a layer of complication that is otherwise unnecessary and might make debugging installation problems that might occur more problematical for you and therefore your client (which won't look good).
If you do use such a product, do so as a convenience: making installation a single (or at least minimal) step process for your clients in order to reduce the risk of human error, rather than as a security measure.
If your concern is more "human factors" such as bad language in code comments or other sources of embarrassment, then discipline and lack of code reviews is the problem, not distribution security, and this needs to be fixed earlier in your process.
As a side note: if by this you mean that you are generating scripts from SQL Server in order to distribute, then you may need to improve your dev process. You should be able to build everything including upgrade packages from source control rather than generating scripts from your dev databases. This may take effort to setup to run smoothly, but it could save you from a collection of failure types in future.