I have an issue when writing the sql query below in SQL Command line. It asks me "Enter a value for lt:" and then gives error
ORA-00933: SQL command not properly ended
I need to properly read the column that includes '<' or '>' as a string. How can I edit the query to make it works?
Delete from authorization1
where role = 'staff' AND object = ' /department/gradstudent/gpa'
AND predicate = ' & l t ; 2.0') AND action = 'read'
Assuming you are using SQL*Plus or SQL Developer as your front end, this issue is that &foo is the syntax for defining substitution variables. You can
set define off;
before running your script to disable substitution variables. That will stop the front end from prompting you for a value.
Related
I am working with Delphi 7 and Firebird 2.0. In my application I am using TIBScript components. The problem arises when I use local variables in the script. Firebird requires the names of local variables to be preceded by a colon in some cases. That’s where the problem lies in. The application stops showing the error message:
Dynamic SQL Error
SQL error code = -104
Token unknown - line 4, column 66
?
The token in question is the colon. Here is how my script looks like:
SET TERM ^ ;
EXECUTE BLOCK AS
DECLARE test_variable INT;
BEGIN
SELECT tt.id FROM test_table tt WHERE tt.name LIKE 'abc%' INTO :test_variable;
INSERT INTO test_table2(id, test_column)
VALUES(1, :test_variable);
INSERT INTO test_table3(id, test_column)
VALUES(1, :test_variable);
...
END^
SET TERM ; ^
The same script executes without any errors when run from IBExpert.
How can I use local variables in a TIBScript? Any help would be appreciated!
I want to add that this problem occurs only with variables inside an EXECUTE BLOCK construct. There is no problem with local variables in stored procedure and trigger definitions.
After executing the method TIBSQL.PreprocessSQL (Unit IBX.IBSQL line 2362), parameters marked with ":" on the front are replaced by "?". So you should use parameters without ":". Also I think it should be removed SET TERM. Instead, to set terminator value use the IBScript.Terminator property.
P.S. I watched unit IBX.IBSQL in Delphi 10.3 Rio.
this
EXECUTE BLOCK AS
DECLARE test_variable INT;
BEGIN
SELECT tt.id FROM USERS tt WHERE (tt.fname LIKE 'abc%') INTO test_variable;
END;
is executed properly when
IBScript.Terminator = ^;
Edit:
You can't execute INSERT with parameters in EXECUTE BLOCK using TIBScript component.
As Mark Rotteveel comented:
Unfortunately removing the colon is only an option in the into clause
in not with other occurrences of local variables or parameters.
How can I execute the following SQL inside a single command (single execution) through ADO.NET?
ALTER TABLE [MyTable]
ADD NewCol INT
GO
UPDATE [MyTable]
SET [NewCol] = 1
The batch separator GO is not supported, and without it the second statement fails.
Are there any solutions to this other than using multiple command executions?
The GO keyword is not T-SQL, but a SQL Server Management Studio artifact that allows you to separate the execution of a script file in multiple batches.I.e. when you run a T-SQL script file in SSMS, the statements are run in batches separated by the GO keyword. More details can be found here: https://msdn.microsoft.com/en-us/library/ms188037.aspx
If you read that, you'll see that sqlcmd and osql do also support GO.
SQL Server doesn't understand the GO keyword. So if you need an equivalent, you need to separate and run the batches individually on your own.
Remove the GO:
String sql = "ALTER TABLE [MyTable] ADD NewCol INT;";
cmd = new SqlCommand(sql, conn);
cmd.ExecuteNonQuery();
sql = "UPDATE [MyTable] SET [NewCol] = 1";
cmd = new SqlCommand(sql, conn);
cmd.ExecuteNonQuery();
It seems that you can use the Server class for that. Here is an article:
C#: Executing batch T-SQL Scripts containing GO statements
In SSMS (SQL Server Management System), you can run GO after any query, but there's a catch. You can't have the semicolon and the GO on the same line. Go figure.
This works:
SELECT 'This Works';
GO
This works too:
SELECT 'This Too'
;
GO
But this doesn't:
SELECT 'This Doesn''t Work'
;GO
This can also happen when your batch separator has been changed in your settings. In SSMS click on Tools --> Options and go to Query Execution/SQL Server/General to check that batch separator.
I've just had this fail with a script that didn't have CR LF line endings. Closing and reopening the script seems to prompt a fix. Just another thing to check for!
Came across this trying to determine why my query was not working in SSRS. You don't use GO in SSRS, instead use semicolons between your different statements.
I placed a semicolon ; after the GO, which was the cause of my error.
You will also get this error if you have used IF statements and closed them incorrectly.
Remember that you must use BEGIN/END if your IF statement is longer than one line.
This works:
IF ##ROWCOUNT = 0
PRINT 'Row count is zero.'
But if you have two lines, it should look like this:
IF ##ROWCOUNT = 0
BEGIN
PRINT 'Row count is zero.'
PRINT 'You should probably do something about that.'
END
I got this error message when I placed the 'GO' keyword after a sql query in the same line, like this:
insert into fruits (Name) values ('Apple'); GO
Writing this in two separate lines run. Maybe this will help someone...
I first tried to remove GO statements by pattern matching on (?:\s|\r?\n)+GO(?:\s|\r?\n)+ regex but found more issues with our SQL scripts that were not compatible for SQL Command executions.
However, thanks to #tim-schmelter answer, I ended up using Microsoft.SqlServer.SqlManagementObjects package.
string sqlText;
string connectionString = #"Data Source=(localdb)\MSSQLLocalDB;Initial Catalog=FOO;Integrated Security=True;";
var sqlConnection = new System.Data.SqlClient.SqlConnection(connectionString);
var serverConnection = new Microsoft.SqlServer.Management.Common.ServerConnection(sqlConnection);
var server = new Microsoft.SqlServer.Management.Smo.Server(serverConnection);
int result = server.ConnectionContext.ExecuteNonQuery(sqlText);
I have a fairly complex SQL query that I am trying to run through RODBC that involves defining variables. A simplified version looks like this:
DECLARE #VARX CHAR = 'X';
SELECT * FROM TABLE WHERE TYPE = #VARX;
Running this code works just fine. This fails:
library(RODBC)
q <- "DECLARE #VARX CHAR = 'X';\nSELECT * FROM TABLE WHERE TYPE = #VARX;"
sqlQuery(ch, q)
# returns character(0)
I have found through experimentation that the first statement before the semicolon is executed, but the rest is not. There is no error--it just seems that everything after the semicolon is ignored. Is there a way to execute the full query?
I'm using SQL server by the way.
NOTE: I asked this question before and it was marked as a duplicate of this question, but they are asking completely different things. In this question I would like to execute a script that contains multiple statements, and in the other the author is only trying to execute a single statement.
You can try this:
library(RODBC)
library(stringr)
filename = "filename.sql" ### file where the sql code is stored
queries <- readLines(filename) ### read the sql file into R
queries1 = str_replace_all(queries,'--.*$'," ") ### remove any commented lines
queries2 = paste(queries1, collapse = '\n') ### collapse with new lines
queries3 = unlist(str_split(queries2,"(?<=;)")) ### separate individual queries
set up the odbc connection at this point and run the for loop below. you can also modify the queries to add/change variables within the queries before running the for loop
for (i in 1:length(queries3)) {
print(i)
sqlQuery(conn, queries3[i])
}
after the for loop is done, you can pull any volatile or regular tables generated in your session into R using sqlQuery(). I havent tested this extensively and there might be cases where it can fail, but it worked for what I was doing
I'm currently using bash on CentOS. DB2 is installed and db2 is on my path.
I have a few lines in a script which are supposed to update my db2 database, but they aren't working. As a minimal reproduction, I can do the exact same thing right in the bash command line and get the same error. Here's that reproduction:
$ db2 connect to PLT02345 user uni using uni; db2 update USM_USER set STATUS = 1 where NAME = 'asm_admin'
I expect this to set STATUS to 1 for everything in PLT02345.USM_USER where the NAME is currently asm_admin.
Instead, I get an error about "ASM_ADMIN" not being valid in the context where it's used. Here's the full output:
Database Connection Information
Database server = DB2/LINUXX8664 10.1.2
SQL authorization ID = UNI
Local database alias = PLT02345
DB21034E The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it returned:
SQL0206N "ASM_ADMIN" is not valid in the context where it is used.
SQLSTATE=42703
I'm confused - what about this makes it not valid? Is bash somehow mutilating the command and not passing everything as it should to db2?
If you're running this from the command line, Bash will drop the 's off 'asm_admin' because it simply assumes you're passing a string. The end result is the SQL becoming WHERE name = asm_admin which is invalid.
To correct this, you need to quote your whole command:
db2 "update USM_USER set STATUS = 1 where NAME = 'asm_admin'"
Does anyone know if what I'm trying to do in the below code is possible and if so what the syntax is? This issue is around the connect call, the username doesn't seem to generate correctly. The commented out connect call is another one I tried.
-- myscript.sql
-- #params:
-- 1 - Oracle database name eg. localhost
-- 2 - Site (site01, site02 site03)
connect systemname_%2_admin/mypassword#&1;
--connect "systemname_" || "%2" || "_admin"/mypassword#&1;
begin
--execution code here.
end;
/
disconnect;
NOTE: Call does need to be this way as this is going to be an automated script doing different things for different usernames.
Your arguments will be stored in substitution variables 1, 2 and so on.
You access them in your script with &1, &2 (so forget about %2, it's meaningless).
Now your problem is that &2_admin looks to sqlplus like a substitution variable named 2_admin so you just need to add a dot . after the 2. Dot is the character that separates the name of a substitution variable from what follows.
your connect will look like :
connect systemname_&2._admin/mypassword#&1
(With no ; : this is a sqlplus command not an sql statement).