This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
How to run a database script file from Delphi?
I have a really long sql script to run with a query, it updates fields, create tables, create procedures, etc. So, there's a lot of the word 'GO' around, otherwise it won't function properly.
On the MSSQL Query the script works perfectly whereas on the ADO Query I get the following:
Incorrect syntax near 'GO'
EDIT: Ok, I think we got it pretty well established that ADO Query will not read the word GO. However, without the word GO my code will not work, procedures must be created in the first line and I have a couple of those thrown around the file. Which is an issue.
The only workaround then would be to create separate queries?
Yes. Remove the GO - it is not valid SQL.
It is syntax specific to Microsoft SQL utilities - see MSDN.
Signals the end of a batch of Transact-SQL statements to the SQL Server utilities.
(emphasis mine)
Go is a batch terminator, it is not SQL, it is understood by SSMS. Just remove the GO when running from ADO
GO is not a SQL command. It is a batch terminator recognized by SSMS
Related
I am trying to install a stored procedures. When I run the query I get Incorrect syntax near the keyword 'tran'
The 'tran' keyword is used in dump tran master with no_log
It would be helpful if anyone help me overcome this issue.
You're getting a syntax error because TRAN isn't a SQL keyword and isn't valid for the syntax of DUMP. See https://technet.microsoft.com/en-us/library/ms187315(v=sql.90).aspx. To use DUMP properly, it's either DUMP DATABASE or DUMP TRANSACTION
Note that per the above link, DUMP is flagged as deprecated and only exists for backwards compatibility. It will go away in the future. You should be using BACKUP (probably BACKUP LOG in this case) instead.
From some SQL Server 2005 documentation on DUMP, I found the following:
The DUMP statement is included for backward compatibility. This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature. Instead, use BACKUP.
I bet that DUMP has already been removed from SQL Server 2014.
I have started doing Sybase programming since some time.the scripts I have encountered are all having GO statements as a batch separator. my question here is is it possible to omit GO in a script and get the script execued?
if yes, will it affect anything at all ?
go is required. It's no different than Oracle and MySQL using ; If you omit the go, the script will not execute.
Since SQL Server does not have a simple batch command line executor for the scripts the are auto generated from management studio, I created one.
The problem arises when delphi ado syntax and SQL Server syntax don't agree (BUT ITS THE SAME THING).
Well any how, the go I replaced with ;
Now as I declare a stored procedure alter, I hit a brick wall.
The script I'm running is :
ALTER Procedure [dbo].[procName]
as
Declare #param int
and the error i get is :
the arguments are from the wrong type,
out of range or collide with one
another.
(my free translation)
questions :
why is this happening?
what can i do to change this?
is there another udl based program that parse SQL scripts?
thanks.
edit: require login to the db with udl file.
could it be that delphi has problems with # ?
Since SQL Server does not have a
simple batch command line executer for
the scripts the are auto generated
from management studio, I created one.
Are you aware of SQLCMD ?? Seems like a command-line utility to execute SQL scripts to me... also: the SQLCMD utility has a number of additional enhancements that go beyond what the T-SQL scripts in SSMS can do.
Also check out:
SQLCMD reference
Using SQLCMD utility
Not sure about your SQL example above, but does the stored procedure actually have any parameters, or are you calling a variable inside the body #param? The usual syntax is:
ALTER Procedure [dbo].[procName]
(<#params here>)
AS
<body + variables here>
MSDN - Alter Procedure
removed the component and change the code from
ado.open;
to
ado.execute;//or something like this
solved it.
I am trying to insert rows into a MySQL database from an Access database using SQL Server 2008 SSIS.
TITLE: Microsoft SQL Server Management Studio
------------------------------
ERROR [42000] [MySQL][ODBC 5.1 Driver][mysqld-5.0.51a-community-nt]You have
an error in your SQL syntax; check the manual that corresponds to your MySQL
server version for the right syntax to use near '"orders"' at line 1
The problem is with the delimiters. I am using the 5.1 ODBC driver, and I can connect to MySql and select a table from the ADO.Net destination data source.
The MySql tables all show up delimited with double-quotes in the SSIS package editor:
"shipto addresses"
Removing the double quotes from the "Use a table or view" text box on the ADO.NET Destination Editor or replacing them with something else does not work if there is a space in the table name.
When SSIS puts the Insert query together, it retains the double quotes and adds single quotes.
The error above is shown when I click on "Preview" in the editor, and a similar error is thrown when I run the package (albeit then from the actual insert statement).
I don't seem to have control over this behavior. Any suggestions? Other package types where I can hand-code the SQL don't have this problem.
Sorry InnerJoin, I had to take the accepted answer away from you. I found a workaround here:
The solution is to reuse the connection for all tasks, and to turn ANSI quotes on for the connection before you do any inserts, with an Execute Sql task that runs the following:
set sql_mode='STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,
NO_ENGINE_SUBSTITUTION,ANSI_QUOTES'
Try using square brackets around the table names. That may help.
EDIT: If you can, I would create views (with no spaces) based on the Access tables, and use those to export. Even if it means building another Access database with linked tables, I think this is your best bet.
I've always struggled with using SSIS with MYSQL directly. Even after installing the ODBC drivers, they just don't play well in data flows. I've always ended up creating linked ODBC connections between SQL Server and MYSQL. I then rely on linked server queries to bring over data. Instead of using a SSIS data flow task, I use an Execute SQL command, usually in the form of a stored procedure that executes an OPENQUERY.
One solution you could do is load the data into a SQL Server database and use it as a staging environment before you load it into the MYSQL database. I regularly move data between SQL Server 2008 and MYSQL and in the past I use to regularly move data between Access and SQL Server.
Another possible solution is to transform the incoming Access data before it loads into the MYSQL database. That may give you a chance to clean up the column names and the actual data that's going through to MYSQL.
Let me know if either of these work for you.
You can locate the configuration setting file my.ini at <<Drive>>:\ProgramData\MySQL\MySQL Server 5.6\my.ini and add "ANSI_QUOTES" to sql-mode.
e.g: sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,ANSI_QUOTES". This should solve the issue while previewing in the SSIS editor.
I've an SSIS package that runs a stored proc for exporting to an excel file. Everything worked like a champ until I needed to a do a bit of rewriting on the stored proc. The proc now takes about 1 minute to run and the exported columns are different, so my problems are the following;
1) SSIS complains when I hit the preview button "No column information returned by command"
2) It times out after about 30 seconds.
What I've done.
Tried to clean up/optimize the query. That helped a bit, but it still is doing some major calculations and it runs just fine in SSMS.
Changed the timeout values to 90 seconds. Didn't seem to help. Maybe someone here can?
Thanks,
Found this little tidbit which helped immensely.
No Column Names
Basically all you need to do is add the following to your SQL query text in SSIS.
SET FMTONLY OFF
SET NOCOUNT ON
Only problem now is it runs slow as molasses :-(
EDIT: It's running just too damn slow.
Changed from using #tempTable to tempTable. Adding in appropriate drop statements. argh...
Although it appears you may have answered part of your own question, you are probably getting the "No column information returned by command" error because the table doesn't exist at the time it tries to validate the metadata. Creating the tables as non-temporary tables resolves this issue.
If you insist on using temporary tables, you can create the temporary tables in the step preceeding the data flow. You would need to create it as a ## table and turn off connection sharing for the connection for this to work, but it is an alternative to creating permanent tables.
A shot in the dark based on something obscure I hit years ago: When you modified the procedure, did you add a call to a second procedure? This might mess up SSIS's ability to determine the returned data set.
As for (2), does the procedure take 30+ or 90+ seconds to run in SSMS? If not, do you know that the query is actually getting into SQL from SSIS? Might be worth firing up SQL Profiler to see what's actually being sent to SQL Server. [Which was the way I found out my obscure factoid.]