Opening large sql script generated by SQL Server publisher cant be open in management studio, returning error about not enough available storage to open it.
Is there some other way to import db from large script ? (command line maybe)
Is this something you have to edit? If so, you may want to open it in Notepad++ or TextPad or Editplus.
Here are some options I can think of:
Use the batch separator GO between sets of commands. The reason for this is that without the GO, SSMS is trying to execute the entire script as a single command. This puts a heavier load on memory requirements than multiple batches would.
To run the script, you can use SQLCMD from the command line.
Also, for large scripts that load data, you may want to ensure that you have COMMIT commands in the script (where appropriate).
Consider splitting your script into multiple scripts.
If you split into multiple files and build the SQLCMD command line syntax, you can run all scripts from a single batch file fairly quickly.
Have you tried using the OSql tool?
Related
I want to run batch file from SQL Job without using exec xp_cmdshell.
Any idea?
Thanks
You could use a SQL Server Job, otherwise i cannot think of a way you could without xp_cmdshell.
Take a look at this
I want to run batch file from SQL Job without using exec xp_cmdshell.
Any idea?
Worth to mention that you can also leverage SQLCLR.
Example: CLR Stored procedure to execute command
Some other googlable threads:
How to execute a DOS command when xp_cmdshell is disabled in SQL Server
Executing an external process() in SQLCLR Project
Such approach introduces severe risks like memory leaks, crashing of underlying .net app pool etc
Therefore another link: Security in the CLR World Inside SQL Server
Instead of running batch file, i have created power shell and ran it from SQL job. It satisfy my requirement and resolved my issue.
Do it like the picture: like this image.
The drive containing the batch file should be other than the C drive, to avoid trouble.
Add execute, read and write permissions for the user, which you are using to run the batch file, to get the username run this query: EXEC master..xp_cmdshell 'whoami', get the name after the \ sign. For example "nt service\mssqlserver". Add permission for this user: mssqlserver
Finally make sure you put the batch file on the same server as where you execute your Job.
Hopefully this question is unique enough not to be a duplicate. I have a PowerShell script which does two things.
Inserts records into a SQL Server table
Writes text to a text file
For the purpose of this post, I have simplified the script. On my computer, the script is located at C:\Temp\ssis.ps1. Following is the contents of the script.
DTEXEC.EXE /F "C:\Temp\ssisjob.dtsx"
$date = Get-Date
Write-Output "This PowerShell script file was last run on $date" >> C:\Temp\test.txt
When I manually run this PowerShell script, records are inserted into the SQL Server table, and a line of text is written to the test.txt file. If I schedule this script to run using Windows Task Scheduler, a new line of text is written to the text file, but the records are not inserted into the SQL Server table. This tells me that Windows Task Scheduler is able to run the PowerShell script. However, for some unknown reason, Windows Task Scheduler seems to not want to run the SSIS job (DTEXEC.EXE) part of the script. Event Viewer confirms there is an issue with the SSIS job. I am running Microsoft SQL Server 2014, Developer Version.
In my task, on the Actions tab, the Add arguments field has the following reference: C:\Temp\ssis.ps1. Task Scheduler is configured to run with the highest privileges.
I have tried all of the following Execution Policies in PowerShell. Regardless of the Execution Policy I select, my experience does not change.
Bypass
Unrestricted
RemoteSigned
The History tab in Task Scheduler has information events, but no error events.
I do not have the permission to view the SQL Server logs (this is a production server).
I have been debugging this issue for a few weeks, and I have read numerous posts here on Stack Overflow, yet I still cannot seem to find the answer, so hopefully I have done my due diligence before making a new post here. I could add some additional observations, but I do not want my post here to get extensively long. If anyone has any hints or tips or insight that might lead me down the right path, it would be greatly appreciated.
Here is the solution I came up with. Instead of exporting the file to Excel, I exported to a flat file (txt file). Also, using Nick McDermaids excellent recommendations, instead of using PowerShell in Task Scheduler, I started the dtexec.exe file in Task Scheduler.
Task Sheduler Actions Tab
Keep the action as Start a program
In Program/script, type dtexec.exe
In Add arguments, type /f "C:\path\to\example.dtsx
Leave the Start In box empty
So I have a lot of table create scripts that I need to run on a fresh database. They are all in one folder, and theirs over 250 of them.
Is there a good way to go about doing this using SSMS?
Option 1: USE BATCH FILE
Using Batch file[to run all the scripts in one click] but that cmd implicitly will use sqlcmd.
Option 2: MERGE MULTIPLE SQL FILES INTO A SINGLE SQL FILE AND THEN EXECUTE IN SSMS IN ONE SHOT
Create a simple batch file under the folder(wherein your 250 table creation scripts reside) as follows
type *.sql > allinone.sql
Note: Open txt document and then copy paste the above content and then save it with extension .bat(Ex:merge.bat)
Just double clicking that batch file will give you the single sql file which you can run in SSMS in single go.
I have an SQL server 2008 database instance on one machine. Now I want to copy this database to another machine. I use the script wizard inside SQL Management Studio to generate a SQl-script with the schema and data. The script-file is rather big (around 17 GB).
Then I run the sql-script on the target machine it results in a :
Msg 105, Level 15, State 1 error with the message:
Unclosed quotation mark after the character string
I do understand the problem of what unclosed quotation marks mean. But I don't understand why the error happens. Isn't the script generator able to handle quotations inside text strings like...hello, what's up...correctly and create a script that will escape such characters?
Is their a limit on the length of text for the script wizard? Is this causing the problem.
I don't want to and I cannot open the script-file in a text editor (too large, text editor will crash) and manually fix the problems.
Do you have any ideas?
Solution for the SQL Server Import Issue
Pre-condition
In order to move the data from one SQL Server to another (e.g. from Production environment to Test environment) makes sense to use "Generate scripts" feature which is available in database options in SQL Server Management Studio. The result of this operation is text file with SQL commands that can be executed on another SQL Server. Usually these files are too big to execute them in SQL Server Management Studio, so we need to use sqlcmd command line utility from SQL Server installation package. In the most cases utility works smoothly and additional user actions are not necessary.
Issue description
In some rare cases the sqlcmd utility can fail with the import and raise the following error: "Unclosed quotation mark after the character string ..." which indicates that one of SQL queries has not been executed. This happens because sqlcmd works using stream processing, i.e. it reads some piece of data, processes it, reads next piece and so on. In some cases an input file can contain huge SQL instruction which size is bigger than the amount of the data that could be processed by sqlcmd at a time, so sqlcmd tries to execute broken SQL and fails.
Possible solutions
In order to fix this issue 2 approaches can be used:
The sqlcmd utility can accept the "-a" parameter which defines the maximum size of packet (piece of data) that will be used during processing. The maximum value is 32767, the default value is 4096, so it makes sense to always use this parameter with maximum value.
sqlcmd -i input.sql -a 32767 -o import_log.txt
If the first approach didn't help and issue still appears, there is another, more difficult solution:
Install the Cygwin
During the installation, after some standard screens, stop on the screen "Select packages"
In "Search" field, enter "sed", and in the tree below expand the "Base" category and choose version not less than 4.2.2 for installation
Complete installation
Note: "sed" is the Linux utility which allows stream-based file processing
After installation is completed, run "Cygwin64 Terminal" from the desktop. We will use it for next steps
Go to the directory where the SQL file generated by SQL Server Management Studio is located. You need to use Linux style slashes "/" instead of Windows style which is "\"
cd d:/temp
Change the encoding of the SQL file from UTF-16LE to UTF-8, because "sed" cannot process UTF-16LE, this conversion is safe for the data. The result will be a new file, that we will use in next step
iconv -f UTF-16LE -t UTF-8 input.sql > input_utf8.sql
Convert the new file, to have one SQL query in one batch. The result will be a new file, that we will use in next step
sed -e 's/^INSERT/GO\nINSERT/' input_utf8.sql > input_utf8_adapted.sql
Now the file "input_utf8_adapted.sql" should be processed by sqlcmd without any issues, so we can execute the following:
sqlcmd -i input_utf8_adapted.sql -a 32767 -o import_log.txt
After execution is done, please check import_log.txt to make sure that no errors appeared
I ended up on this question after trying to find a solution to a similar problem I had. I also needed to dump a DB (with data) via Generate scripts wizard and the resulting file was too big to be executed from SSMS. So I tried the sqlcmd but ended with the error
Sqlcmd: Error: Syntax error at line 10 near command '"' in file 'script.sql'.
It turned out the cause of the issue was a record containing data with jQuery syntax in it - $(".someclass"). It's because it is also a way how to insert a variable into sqlcmd.
The solution is to disable variable substitution by adding -x command line argument.
Not a direct answer to the question but to duck this issue you could use one of the following other methods of copying the database to the new location.
Copying Databases with Backup and Restore
Using Detach and Attach
Method 1 is usually preferable as it keeps the source DB online and detaching can cause information held in the master database about the source to be lost (e.g. full text enabled status)
EDIT: Just noted from your comment that you're running sqlcmd -S server\database -i script.sql. There is a -I switch that stands for "Enable Quoted Identifiers". Try to run the command with this switch.
Btw, to edit a large file, consider using a nice editor like Notepad++ or UltraEdit. I wouldn't use a workstation without em :)
If I have scripts in multiple files, and I would like to execute each one in a known sequence, can I simply import them into a T-SQL script and execute them, or must I run sqlcmd or similar against each file? I'm sure Oracle has a feature to import/include script content from another file (maybe with ## ?).
I want all of the scripts to run automatically. I.e. I don't want to manually load and run each file of SQL script.
If you want to run the scripts automatically I'd make a batch file which calls osql for each file.
-Edoode
You can concatenate the scripts into a single file. Place a GO statement at the end of each file (if it doesn't already have one) and it should be fine to run as one file instead of multiple.
I think you can import them into a T-SQL script and execute. Better yet though, use SSMS and a maintenance plan. That way you can run the individual SQL and have some checks on success before executing the next statements.
We have a free simple tool you can use as well - it is called Script Executor - the community edition (http://www.xsqlsoftware.com/Product/Sql_Server_Script_Executor.aspx) allows you to add individual scripts and folders containing scripts, order them and execute. There is a command line option as well in case you need to schedule the execution to run automatically.