I am releasing a database build to SQL Server 2000 via a batch file using isql. The batch file is used so multiple files are released consistently to different SQL Servers (development, test, live).
The SQL Server uses ANSI code page 1252 (from sp_helpsort) but isql is an OEM client using code page 437. This means that all extended characters (with ASCII code > 128) are converted when the scripts are run, leading to inconsistent results when characters like “£” are included in the script. Differences are explained in this Microsoft knowledgebase article.
Possible solutions are: -
Save the script using Unicode and
use osql.
Turn off the AutoAnsiToOem setting using the SQL Server Client Network Utility (that writes a registry key).
Both these options rely on various people doing things consistently. All have to select the same code page option when saving a file OR all people performing the builds have to have the same option set for AutoAnsiToOem.
Is there a way to force the use of a code page either in the SQL script OR in the batch file that calls it, so that the build is always released consistently, regardless of how the file is saved or the various settings of whoever performs the release?
isql is obsolete. It isn't included in SQL Server 2005 or later, because it uses the DB-Library connections, which are also obsolete. For the reasons why, and the effects this has, see Connecting Early Version Clients to SQL Server 2000.
osql uses ODBC connections to connect to SQL Server. For completeness, this has been supplemented by sqlcmd in SQL Server 2005, which uses OLE DB with the SQL Native Client provider.
Further to the accepted answer, I have tested using sqlcmd against a SQL Server 2000 database and it works. You obviously have to run sqlcmd from a machine with the SQL Server 2005 client tools installed.
Related
I am trying to write unit/integration test cases for a Java codebase connecting to MS SQL Server. In this effort, am able to successfully copy all my SQL Server tables over to a H2 Database file and run my unit tests on the H2 DB.
I have thoroughly reviewed the H2 DB Compatibility features.
On my JDBC URL, I have the mode set -
jdbc:h2:~/test;MODE=MSSQLServer
Attempted connecting to the H2DB file and executed
SET MODE MSSQLServer
I attempted this on both in-memory and file mode and both are not working in compatibility mode.
Both these do not seem to work. My application SQLs contain NOLOCK hints and identifiers with square brackets. Both these are quoted to be supported in the compatibility documentation. I even reviewed the H2DB's github for their MS SQL Server unit test and found these to be supported.
Still wondering anything that I may be missing.
Finally figured out that I was using an old version 'h2-1.4.197' where MS SQL Server compatibility is not enabled.
So upgraded to version 'h2-1.4.200' where hints like (NOLOCK) are being ignored once we are on SQL Server mode. Square brackets are still not being ignored - but guess atleast the compatibility mode is working. So will leave it at this.
We have an application called IpSwitch Whatsup and it's installed in a machine that I can connect to remotely as administrator. This is all in our intranet.
We need to connect to the sql server database being used by IpSwitch Whatsup, but this particular machine doesn't have sql server installed. On the other hand, in sql server configuration manager there is indeed a sql server installation for whatsup (the entry says SQL Server (WHATSUP)).
So, two questions:
How does one go about in connecting to this database? I'm pretty sure I know the name of the database and I already know the server name and instance, so I would like to connect to this DB from a sql server installation in another machine.
How does one configure a sql server installation to receive remote connections if it doesn't have sql server installed?
Thanks.
For the first question, you just type in (or browse) the appropriate instance name and authentication options using SSMS - which is the GUI tool used to manage sql server instances. Note - the term "sql server installation" can mean different things so it is not a useful reference.
As for the second question, review the information here. Note that any task you do in SSMS can be done via tsql - you can see the appropriate commands using the script button in the SSMS dialog windows.
And you can also (and probably should based on these questions) install SSMS on the same machine as your server instance so you can do "anything" "anywhere". Now would probably be a good time to review your disaster recovery options (and start backing up your databases regularly).
We recently identified a security floor in some old code which was vulnerable to SQL injection attack.
The server is MS SQL Server 2012 running on Windows 2012.
During the investigation I have been asked if any malicious code has been installed via the vulnerability. The SQL server is once removed from the Webserver but does have access to the internet for Operating system Updates.
I was not aware and haven't heard of code being installed / downloaded via SQL injection and my immediate response would be no this isn't possible. However I thought I would ask the good people on Stack Overflow as there is always the possibility I'm wrong :)
Yes, SQL server can execute master..xp_cmdshell command which executes windows command line operations, allowing further taking over the server and installing things on it.
SQL Server also supports C# code embedding. I would take the server for forensics analysis if its important, or delete it altogether if it's not.
There is the sql-cli utlity (installed with npm) which I am using to connect to various SQL Server machines. It works perfectly, however when connecting to localdb it responds with an error. So the next command line works:
mssql -s SomeServerAddress
But this one doesnt work:
mssql -s (localdb)\v11.0
And it responds with
\v11.0 was unexpected at this time.
Is there any special formatting for the server name to work?
Thanks.
its because (localdb)\v11.0 is not an actual instance as it can only be used inside visual studio.
"The localdb is at the heart of SSDT; it’s similar to SQL Server Express under the hood and runs a full version of sqlserver.exe. However this is throttled by the numbers of CPUs and limits on resources. There are quite a lot of limitations; you cannot upgrade the instance and there is no management and the sqlserver.exe does not run as a service. It is not similar to SQL Server Compact as this is feature-less (no stored procedures or functions) it is actually a DLL file that runs in a process from within Visual Studio, but is not available to task manager or windows. It is awakened when the SQL Server Native Client requests a connection from within Visual Studio. It doesn't stay online forever, it shuts down after time. You can configure where it creates the SQL files required to run. The localdb does not support table partitioning or data compression at the moment. However there are not many features that it does not support. You can however configure SSDT to use a full version of SQL Server i.e. the Developer edition, if your project requires unsupported features; by changing the Debug Connections tring in the projects properies." - Andrew J Fenna
This works:
mssql-cli -E -S (localdb)\mssqllocaldb
The -E is for integrated auth, the -S is the server.
If it does not connect, try to start localdb:
sqllocaldb start mssqllocaldb
This is all that is needed. No need to start Visual Studio or any other tool.
You may alreaady have gone on to bigger and better things, but
mssql -s "(localdb)\MSSQLLocalDB"
has worked for me.
Regards
I am interested in using some kind of a command-line utility for SQL Server similar to Oracle's SQL*Plus. SQL Server seems to have several options: osql, isql, and sqlcmd. However, I am not quite certain which one to use.
Do they all essentially do the same thing? Are there any situations where it is preferable to use one over the others?
Use sqlcmd-- it's the most fully featured product.
sqlcmd: The newest, fanciest command-line interface to SQL Server.
isql : The older, DB-Library (native SQL Server protocol) way of command-line communication with SQL Server.
osql : The older, ODBC-based way of command-line communication with SQL Server.
EDIT: Times have changed since I replied on this a couple of years ago. Nowadays, you can also use the invoke-sqlcmd cmdlet in PowerShell. If you're used to PowerShell or plan to do any scripting of any sophistication, use this instead.
I'm not sure what the scope of your question is, but I believe :
isql used DB-Library to communicate to the server and is no longer included after SQL2000
osql used ODBC to communicate to the server and will no longer included after SQL2005
sqlcmd used OLE DB to communicate to the server and is currently the recommended command line tool.
Its always better to use SQLCMD instead of OSQL or ISQL if you have SQL SERVER 2005, otherwise use OSQL instead of ISQL.
Microsoft has announced before that ISQL was on its way out. Sure enough, ISQL is not included in SQL Server 2005 RTM. OSQL eventually will be phased out also, although it is still included in SQL Server 2005 binary install. With the historical SQL Server release cycle in mind, maybe OSQL will bid us adieu in 2010.
SQLCMD has many advantages as below:
1) Performance wise
2) SQLCMD supports parameterized variables
3) SQLCMD support Customized editor
4) :XML [ONOFF]
5) :Error STDERRSTDOUT
6) :Perftrace STDERRSTDOUT
7) Remote Dedicated Admin Connection (DAC)
There is a free tool "SQLSPlus" (on http://www.memfix.com ) which is exactly like Oracle SQLPlus for SQL Server. Works with all SQL Server versions.
Very flexible with data formatting (set lines size, pagesize, etc), variables (var, &, &&), spool, HTML output, etc - lots of added functionality comparing to isql, osql or sqlcmd