I'm not a DB person but something weird is happening in Access:
I'm trying to run this SQL command: UPDATE tbl_DirectorySet SET TempRootDir='D';
on this table:
It doesn't do anything! I mean the field is empty as before.
If I manually set the field with some value like "aaaaa", then after I run the SQL command I can see that the command worked as expected.
If you don't have any record in a cell, the UPDATE command won't work. Use INSERT instead. That's why it works when you first introduce "aaaaa" and then you UPDATE.
EDIT: this link may make you understand better the principles behind the basic SQL commands: https://en.wikipedia.org/wiki/Create,_read,_update_and_delete
Using Navicat, I am running an SQL Merge Command, Navicat seems to drop off the ; from the end of the command, causing it to fail.
I can't find a way to change the terminator character to something like #.
well, I kinda gave up on it. :-) I just put it in a Stored Procedure - works fine, but I was hoping to find a "query" fix.
Context
We're changing our install scripts to use ant's "sql" task and jdbc rather than proprietary sql clients sqlplus (oracle) and osql (msft).
Updated: added more context. Our "base data" (seed data) consists of a collection of .sql files containing "vendor-neutral"(i.e. works both in oracle and mssql) sql statements.
The Problem
The scripts run fine, with one exception:
This sql fails in Oracle. Specifically, something (ant or jdbc driver) treats the dashes/hyphens as "beginning of a comment"--even though they are embedded in a string. Note that the same sql works fine with ant/sql and microsoft's jdbc driver.
INSERT INTO email_client (email_client_id,generated_reply_text) VALUES(100002,'----- Original Message -----');
Related Bug
This ant bug appears to identify the problem. As it's still open (after 8 years), I'm not hoping for a fix soon. However, because the problem appears only in oracle, it may lie with the driver.
The oracle driver: jdbc thin driver, version 10.2.0.1.0
The Question
Does anyone have a workaround which works in both mssql and oracle? (e.g. changing the offending lines to define an escape character? I don't see an 'escape' on the 'insert' sql92 syntax)
thanks
After viewing the 'SQLExec' source and turning on verbose logging, I found a workaround:
Workaround
if the sql statement includes a string containing '--', place the delimiter (semi-colon) on the next line.
This Fails
INSERT INTO email_client (email_client_id,generated_reply_text) VALUES(100002,'----- Original Message -----');
This Succeeds
Note that semi-colon is on a separate line
INSERT INTO email_client (email_client_id,generated_reply_text) VALUES(100002,'----- Original Message -----')
;
Details
Turning on verbose logging, I saw that when Ant came across the offending sql statement, it actually passed three sql statements in at once to the jdbc driver. The offending statement, the next statement (which also included an embedded '--'), and the subsequent statement (which did not include an embedded '--').
I gave the Ant code a quick glance and didn't see any obvious errors. Since I wasn't planning to patch Ant, I looked for a workaround.
Tweaking with it I found that if I simply moved the delimiter (semicolon) to the next line for the statements with embedded '--', the scripts executed successfully.
thanks everyone for weighing in
You could try this:
INSERT INTO email_client (email_client_id,generated_reply_text)
VALUES(100002,LPAD('-',5,'-') || ' Original Message ' || LPAD('-',5,'-'));
I reviewing some PL/SQL code and I came across the following in the scripts:
/
SHOW error
grant execute on someName1 to someName2;
/
SHOW error
Reviewing the documentation for PL/SQL I could not find an explanation what the /'s do.
Can anyone enlighten me?
Update: I opened the file that includes this script in SQL Developer for Mac. Compiling it gives the error "encountered the symbol '/'". Should these slashes be removed?
"/" executes the sql command in the current buffer. It similar to GO of SQL Server
The slash basically executes the latest command stored in the buffer.
It's kind of a clunky thing, but a lot of PL/SQL interpreters/engines like SQL Plus require you to enter a "/" after every complete statement to actually execute it and see the results.
http://download.oracle.com/docs/cd/B28359_01/server.111/b31189/ch12004.htm#SQPUG162
Does anyone know why.
CREATE PROCEDURE My_Procedure
(#Company varchar(50))
AS
SELECT PRD_DATE
FROM WM_PROPERTY_DATES
WITH (NOLOCK)
WHERE PRD_COMPANY = #Company
GO
Gives me an error message in SQL management studio:
Msg 102, Level 15, State 1, Procedure My_Procedure, Line 1
Incorrect syntax near 'GO'.
Now, this is the last statement of a batch, maybe the last statement should not have a GO ?
If you go to "Save As...", click on the little down-arrow on the Save button and select "Save with Encoding..." then you can set your Line endings to Windows (CR LF). That seems to have resolved the issue for me...
There was a bug released in SQL Server that parses the GO statement incorrectly. I believe it was introduced when you could do GO X, and execute the batch X multiple times.
Sometimes I've had to add a comments section ("--") to force the parser to terminate rather than produce a syntax error. This has been seen when I've had 400,000 lines in a batch of code.
Example:
PRINT "This is a test."
GO --
PRINT "This is not a test."
GO 5 --
The sql you currently have in the question will work properly. The unformatted sql you had before Kev edited the post won't. The reason is that you had the GO on the same line as the sql. It needs to be on a separate line.
If you copy-paste text from text editor with Unix/Mac EOLs (e.g. Notepad++ supports this) the GO is interpreted as being on the same line as the last TSQL statement (yet on the screen you can see newlines normally). Converting EOLs to Windows (CRLF) in the text editor fixed the problem. Very tricky though.
Error for this sql
ALTER PROCEDURE My_Procedure
(#Company varchar(50))
AS
SELECT PRD_DATE
FROM WM_PROPERTY_DATES
WITH (NOLOCK)
WHERE PRD_COMPANY = #Company GO
is
Msg 102, Level 15, State 1, Procedure My_Procedure, Line 7
Incorrect syntax near 'GO'.
note the Line 7, original question has Line 1.
If I put the GO on its own line SQL works fine.
Given that your error message says Line 1, it would appear that for some reason there isnt a correct CR/LF happening in your sql.
You can certainly have GO at the end of your batch. I see nothing wrong with this code per se. Put a semicolon after #Company.
I tried this SQL on my 2008 server by creating a table WM_PROPERTY_DATES and adding 2 columns, PRD_DATE and PRD_COMPANY.
Work just fine and creates the proc. Maybe you can try putting your code in a BEGIN...END block and see if the issue persists.
Raj
You said
Now, this is the last statement of a
batch, maybe the last statement should
not have a GO ?
This implies that these lines are all part of the same batch submitted to SQL. The thing is, a CREATE PROCEDURE (or CREATE FUNCTION or CREATE VIEW) statement must be the first statement in the batch. So, put a "GO" line in front of that CREATE statement, and see what happens.
Philip
In my case I had copied part of the code from a webpage and it seems that saved the page with different encoding, I tried SaveAs from SMS with different encoding, but didn't work.
To fix my issue I copy the code into NodePad, then save it in ANSI format and re-open the query
No serious company could possibly pretend to add GO after each statement. Perhaps after each batch.
GO is not a Transact-SQL statement. Is a delimiter understood by tools like ISQLW (aka. Query analizer), osql, sqlcmd and SSMS (Management Studio). These tools split the SQL file into batches, delimited by GO (or whatever is the 'batch delimiter' set, to to be accurate, but is usually GO) and then send to the server one batch at a time. The server never sees the GO, and if it would see it then it would report an error 102, incorrect syntax, as you already seen.