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
Related
I am trying to downgrade a SQL Server 2014 database to a lower version (SQL Server 2012) by using the task Generating scripts found when right clicked on the database.
After I make the settings in order to generate the script, the server does that but when I'm trying to open the file (the script made) on a lower version instance of SQL Server, I get the following error.
System out of memory exception thrown
Could anyone provide some help? Thanks!
As suggested by #usr you can run the script from the command line using sqlcmd:
sqlcmd -S myServer\instanceName -i C:\myScript.sql
Alternatively you can download a trial edition of ApexSQL or Redgate SQL Compare (assuming you have not tried them already) and script over the changes using these tools.
The script is too big for SSMS (a shame!). Run it using SQL Server command line tools.
I find it easier to do this by using Redgate SQL Packager or the two compare tools. They can execute enormous scripts.
My MVC3 application is using an SQL Server 2008 to store data. In particular - support ticket management data.
I have a table in a database - Tickets.
I are reviewing a possibility of implementing a recurring ticket registration, using an SQL Server features.
Is there a built-in SQL Server functionality, that would allow me to schedule, a, for example, once a week creation of a row in a database table?
I would use the SQL Server Agent and run a Transact-SQL Job Step.
Note that the agent runs as a service under a particular account, which will need rights to be able to carry out whatever operations your need.
Unfortunately you haven't mentioned your SQL Server Edition. If you have Express then there is no built-in scheduler so you need to use the Windows scheduler to run a batch file or other program that connects to SQL Server.
If you have any other edition, then you have SQL Agent which is a full scheduler with support for just about any task including running SQL statements.
You can easily use the Windows SchedTask Control Panel to schedule a batch file to run periodically:
In the batch file create a SQL string like so:
SET SQLSTRING=INSERT INTO Persons^
VALUES (4,'Nilsen', 'Johan', 'Bakken 2',^
'Stavanger');
Then, just enable delayed expansion and use something like this:
sqlcmd.exe -b -S localhost -E -d !DBNAME! -Q "!SQLSTRING!" -W
In SQL Server Management Studio I would like to know what is SQLCMD mode?
I did some more research, so here's my understanding of this to extend what has been written so far:
What is SQLCMD
SQLCMD.exe is a console utility included in the instalation of SQL Server 2005 and higher. You can typically find it in a path like c:\Program Files\Microsoft SQL Server\100\Tools\Binn\SQLCMD.EXE.
It is a simple scripting environment that allows automation of tasks related to SQL server. For example, you can write and execute a script that will login to a specific instance of SQL Server, execute scripts from a given directory on this connection and store the output in a specified file.
Invoke-Sqlcmd cmdlet was introduced with SQL Server 2008 as a mean to replace this tool with a standardized, Powershell-based approach, preserving most of the original syntax and functionality.
What is SQLCMD mode in SSMS
In SSMS, SQLCMD mode is a script execution mode that simulates the sqlcmd.exe environment and therefore accepts some commands that are not part of T-SQL language.
Unlike sqlcmd.exe, it contacts the database using SqlClient (the same way as SSMS), not ODBC data provider, so in some aspects it might have different behaviour than sqlcmd.exe.
Executing scripts in SQLCMD mode allows to use commands typical to sqlcmd.exe environment. However, there's no IntelliSense or debugging support for SQLCMD mode, so maintaining scripts that mix clean T-SQL with SQLCMD-specific code can be a pain. Therefore, it should be used only when it's necessary.
Example use case
Let's suppose that a company has a naming convention for databases that include environment in the name, eg: MyDb_Prod, MyDb_Test, MyDb_Dev. This convention might be used to minimize chance of mistakes.
When a developer writes a T-SQL script, it will have to be executed in different environments in deployment/testing process, which would require many versions of the code:
SELECT *
FROM [MyDb_Dev].[dbo].[MyTable1] -- MyDb_Dev -> MyDb_Test -> MyDb_Prod
Instead, we can assume that database name will be provided as a SQLCMD variable in deployment process and have exactly the same file deployed to all environments:
-- :setvar databaseName "MyDb_Dev" -- uncomment for testing in SSMS
SELECT *
FROM [$(databaseName)].[dbo].[MyTable1]
(in this simple example database name could be omitted altogether, but if you have cross-database joins, using database name is necessary)
Exactly what it sounds like.
It is a mode that lets you author SQLCMD scripts.
From MSDN - Editing SQLCMD Scripts with Query Editor:
To use the Database Engine Query Editor to write or edit SQLCMD scripts, you must enable the SQLCMD scripting mode.
In SQL Server Management Studio, set this via the Query menu (Query -> SQLCMD Mode).
"You use SQLCMD scripts when you have to process Windows System commands and Transact-SQL statements in the same script."
"By default, SQLCMD mode is not enabled in the Query Editor. You can enable scripting mode by clicking the SQLCMD Mode icon in the toolbar or by selecting SQLCMD Mode from the Query menu."
Reference: MSDN
Message Transact-SQL IntelliSense is not active for this editor because the editor is in SQLCMD mode.
I was publishing SQL Server Project from Visual Studio to Database to synchronize changes and got an error above. Publishing was failing.
I closed all open files in VS and it resolved the issue.
I hope real life example explained why people use SQLCMD mode.
I downloaded the 53.5 MB setup of SQL Server 2005 Express from this URL:
Microsoft SQL Server 2005 Express Edition
Then I ran sqlcmd by going into command promp , but it shows error
HResult 0x2, Level 16, State 1
Named Pipes Provider: Could not open a connection to SQL Server 2.
Sqlcmd: Error: Microsoft SQL Native Client : An error has occurred
while establishing a connection to the server. When connecting to SQL Server 2005,
this failure may be caused by the fact that under the default settings SQL Server
does not allow remote connections..
Sqlcmd: Error: Microsoft SQL Native Client : Login timeout expired.
Then I downloaded and installed Sql Command Line Utility from this URL:
Feature Pack for Microsoft SQL Server 2005 - November 2005
Then also it shows the same error.
Then I installed Sql Native Client, then also it didn't work. But when I installed Management Studio, then from Management Studio the connection is established, but not from sqlcmd from Command Prompt.
Please help.
"Just typing sqlcmd on its own won't work - how should the utility know what server to connect, what database to use, and what command to run??"
Funny thing. As I read the Microsoft documentation, just typing sqlcmd while sitting on the server should open a connection to this server. At least it can, depending on settings for security. Typing sqlcmd without any options for login/security may very well fail, but the utility will defintely try.
And SQLCMD without quit is just that, right?
What if you do something like:
sqlcmd -S W\SQLEXPRESS -E -d master -q "select * from sys.tables"
Just typing sqlcmd on its own won't work - how should the utility know what server to connect, what database to use, and what command to run??
You need to tell sqlcmd what you want to do! Get a list of its command options using sqlcmd -?, study them, and use them! Or read the MSDN docs on Using the sqlcmd utility with SQL Server Express - btw: searching MSDN for answers and documentation would be a good idea for all your SQL Server problems......
The SQL Native Client is definitely needed, yes - not sure what you mean by the second package there.
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.