Whenever I issue 'alter session force parallel DML;' from Pro*C I get an error. Although, it works fine from sqlplus for the same user. Is there any reason for that?
This isn't directly related to Pro*C. The error ORA-12841: Cannot alter the session parallel DML state within a transaction happened in Pro*C because it had already performed DML, whereas a new SQL*Plus session did not. Moving the COMMIT or the ALTER statement should resolve the issue.
Thanks to Hemant K Chitale and €$ħ₪ on the Oracle Forum: https://community.oracle.com/message/10002348
Are you sure that the trailing semicolon ';' is part of the SQL statement?
Usually it only tells sqlplus that the SQL statement end here, but the semicolon is not part of the SQL syntax (except for PL/SQL)
Related
I accidentally included the word "data" in a SQL script I wrote and now am not sure what this does. Can someone tell me what the following script would actually do if the Rollback transaction were not set?
Begin Transaction
data
Rollback Transaction
I think "Data" is in the future reserved keyword list in our SQl Server. But I'm not sure if this is why the script runs without error.
Begin Transaction
data
Rollback Transaction
Not sure what happened. The script ran correctly
You are aliasing the transaction as data
Without the rollback you would just have an open transaction called data
according to my knowledge and the keywords for SQL Server, disponible here:
https://learn.microsoft.com/pt-br/sql/t-sql/language-elements/reserved-keywords-transact-sql?view=sql-server-2017
there is no meaning for data word, but it could be an abbreviation for database, or it could just be a bug
I am new to the stored procedure in oracle and my simple code wont compile in oracle toad.
Here is my code:
code
There is a readline under the ALTER, and it says "Found: "ALTER", expecting select or (: BEGIN BASE COSE...) " why is that?
Oracle doesn't allow you to use DDL natively in PL/SQL. To work around this, you can use EXECUTE IMMEDIATE to run the DDL as a dynamic query.
Running following statement in DB2 CLP (Command Window)
db2 "truncate table MYSCHEMA.TABLEA immediate"
DB21034E The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it returned:
SQL0969N There is no message text corresponding to SQL error "-20356" in the
message file on this workstation. The error was returned from module
"SQLNQBE2" with original tokens "MYSCHEMA.TABLEA".
Can some please tell me what I'm doing wrong or what I'm missing? I'm trying to simply truncate from a single table and I'm getting the following error message. Not sure what I'm doing wrong. I've tried it with/without quotes, with/without schema, with/without immediate. I've also tried in Command Editor (remove db2 and quotes) and still not working. I'm using:
DB2/AIX64 9.7.9
Also, I have delete privilege as I am able to delete records but I want to truncate.
Thanks in advance!
The version of the DB2 client you're using doesn't seem to match that of the server, this is why you cannot see the actual error message for SQLCODE -20356. If you could, you'd see this:
The table MYSCHEMA.TABLEA cannot be truncated because DELETE triggers
exist for the table, or the table is the parent in a referential
constraint.
Further explanation and suggested actions can be found, as usual, in the fine manual.
ALTER TABLE MYSCHEMA.TABLEA ACTIVATE NOT LOGGED INITIALLY WITH EMPTY TABLE
or
import from /dev/null of del replace into MYSCHEMA.TABLEA
I had this problem recently too. In my case I had to do a COMMIT WORK right before TRUNCATE. This solved my problem. Please try and tell us if this helped.
I use ADO.NET as well as the sqlcmd utility to send SQL scripts to SQL Server 2008. What is the difference between using ; and GO to separate chunks of SQL?
GO is not actually a T-SQL command. The GO command was introduced by Microsoft tools as a way to separate batch statements such as the end of a stored procedure. GO is supported by the Microsoft SQL stack tools but is not formally part of other tools.
You cannot put a GO into a string of SQL and send it as part of a ADO.NET command object as SQL itself does not understand the term. Another way to demonstrate this is with the profiler: set up some statements that use GO in Query Analyzer/Management Studio and then run the profiler when you execute. You will see they are issued as separate commands to the server.
The semi-colon is used to signify the end of a statement itself, not necessarily a whole batch.
http://msdn.microsoft.com/en-us/library/ms188037.aspx
"GO" is similar to ; in many cases, but does in fact signify the end of a batch.
Each batch is committed when the "GO" statement is called, so if you have:
SELECT * FROM table-that-does-not-exist;
SELECT * FROM good-table;
in your batch, then the good-table select will never get called because the first select will cause an error.
If you instead had:
SELECT * FROM table-that-does-not-exist
GO
SELECT * FROM good-table
GO
The first select statement still causes an error, but since the second statement is in its own batch, it will still execute.
GO has nothing to do with committing a transaction.
semicolon is a statement separator. The previous statement(s) is not necessarily executed when a semicolon is encountered.
GO
Signifies the end of a batch. Executes the previous batch of statements, as does encountering the end of the block.
GO 2
Means execute the batch that many times. I think I've used that option maybe twice in my life. Then again, I'm not a DBA by trade.
Under SQL Server TSQL (2005 - 2016) bear in mind that:
Semicolon (;) is a block terminator.
GO is a batch terminator.
Additionally, GO can be used to invoke the same DML block multiple times using the following syntax:
GO [count]
Where [count] is a positive integer that indicates how many times the TSQL block of commands preceding said GO are to be carried out over and over.
Also, unlike semicolon, GO is mandatory before a new DDL, say, when you create a new view, since a semicolon separating previous commands will trigger an error. For example:
drop view #temporary_viewGO
create view #another_view...
--> NO ERRORS
If you replaced GO with a semicolon in the previous example, it will raise the following error message:
'CREATE VIEW' must be the first statement in a query batch.
'GO' is typically used to indicate the end of a batch of SQL statements which means that you could have a begin transaction and end transaction wrapped up into a single collection of statements that could fail or succeed together.
';' is generally used to separate multiple SQL statements from one another. This is noticable in SQL scripts that need to return multiple recordsets, such as `select * from table1; select * from table2;' which would result in two separate recordsets on the client's side.
The command GO means the end of a batch.
Therefore all variables declared before GO are invalid after the GO command.
Against the semicolon does not end the batch.
If You will use a DML command in a procedure, use the semicolon instead GO.
For example:
CREATE PROCEDURE SpMyProc
#myProcParam VARCHAR(20)
AS
DECLARE #myOtherParam INT = 5
;DISABLE TRIGGER ALL ON tMyTable
UPDATE tMyTable SET myVar = #myProcParam, mySecondVar = #myOtherParam
;ENABLE TRIGGER OLL ON tMyTable
I thought the ; character separates a list of SQL commands, GO just instructs SQL Server to commit all the previous commands.
We have been having some debate this week at my company as to how we should write our SQL scripts.
Background:
Our database is Oracle 10g (upgrading to 11 soon). Our DBA team uses SQLPlus in order to deploy our scripts to production.
Now, we had a deploy recently that failed because it had used both a semicolon and a forward slash (/). The semicolon was at the end of each statement and the slash was between statements.
alter table foo.bar drop constraint bar1;
/
alter table foo.can drop constraint can1;
/
There were some triggers being added later on in the script, some views created as well as some stored procedures. Having both the ; and the / caused each statement to run twice causing errors (especially on the inserts, which needed to be unique).
In SQL Developer this does not happen, in TOAD this does not happen. If you run certain commands they will not work without the / in them.
In PL/SQL if you have a subprogram (DECLARE, BEGIN, END) the semicolon used will be considered as part of the subprogram, so you have to use the slash.
So my question is this: If your database is Oracle, what is the proper way to write your SQL script? Since you know that your DB is Oracle should you always use the /?
I know this is an old thread, but I just stumbled upon it and I feel this has not been explained completely.
There is a huge difference in SQL*Plus between the meaning of a / and a ; because they work differently.
The ; ends a SQL statement, whereas the / executes whatever is in the current "buffer". So when you use a ; and a / the statement is actually executed twice.
You can easily see that using a / after running a statement:
SQL*Plus: Release 11.2.0.1.0 Production on Wed Apr 18 12:37:20 2012
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning and OLAP options
SQL> drop table foo;
Table dropped.
SQL> /
drop table foo
*
ERROR at line 1:
ORA-00942: table or view does not exist
In this case one actually notices the error.
But assuming there is a SQL script like this:
drop table foo;
/
And this is run from within SQL*Plus then this will be very confusing:
SQL*Plus: Release 11.2.0.1.0 Production on Wed Apr 18 12:38:05 2012
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning and OLAP options
SQL> #drop
Table dropped.
drop table foo
*
ERROR at line 1:
ORA-00942: table or view does not exist
The / is mainly required in order to run statements that have embedded ; like CREATE PROCEDURE,CREATE FUNCTION,CREATE PACKAGE statements and for any BEGIN...END blocks.
I wanted to clarify some more use between the ; and the /
In SQLPLUS:
; means "terminate the current statement, execute it and store it to the SQLPLUS buffer"
<newline> after a D.M.L. (SELECT, UPDATE, INSERT,...) statement or some types of D.D.L (Creating Tables and Views) statements (that contain no ;), it means, store the statement to the buffer but do not run it.
/ after entering a statement into the buffer (with a blank <newline>) means "run the D.M.L. or D.D.L. or PL/SQL in the buffer.
RUN or R is a sqlsplus command to show/output the SQL in the buffer and run it. It will not terminate a SQL Statement.
/ during the entering of a D.M.L. or D.D.L. or PL/SQL means "terminate the current statement, execute it and store it to the SQLPLUS buffer"
NOTE: Because ; are used for PL/SQL to end a statement ; cannot be used by SQLPLUS to mean "terminate the current statement, execute it and store it to the SQLPLUS buffer" because we want the whole PL/SQL block to be completely in the buffer, then execute it. PL/SQL blocks must end with:
END;
/
It's a matter of preference, but I prefer to see scripts that consistently use the slash - this way all "units" of work (creating a PL/SQL object, running a PL/SQL anonymous block, and executing a DML statement) can be picked out more easily by eye.
Also, if you eventually move to something like Ant for deployment it will simplify the definition of targets to have a consistent statement delimiter.
Almost all Oracle deployments are done through SQL*Plus (that weird little command line tool that your DBA uses). And in SQL*Plus a lone slash basically means "re-execute last SQL or PL/SQL command that I just executed".
See
http://ss64.com/ora/syntax-sqlplus.html
Rule of thumb would be to use slash with things that do BEGIN .. END or where you can use CREATE OR REPLACE.
For inserts that need to be unique use
INSERT INTO my_table ()
SELECT <values to be inserted>
FROM dual
WHERE NOT EXISTS (SELECT
FROM my_table
WHERE <identify data that you are trying to insert>)
From my understanding, all the SQL statement don't need forward slash as they will run automatically at the end of semicolons, including DDL, DML, DCL and TCL statements.
For other PL/SQL blocks, including Procedures, Functions, Packages and Triggers, because they are multiple line programs, Oracle need a way to know when to run the block, so we have to write a forward slash at the end of each block to let Oracle run it.
I only use the forward slash once at the end of each script, to tell sqlplus that there is not more lines of code. In the middle of a script, I do not use a slash.
use semicolon in sql script files to separate sql statements that tell client software (SQL*Plus, SQL Developer) what are the single statements to be executed.
use slash in sql script files to separate pl/sql blocks that tell client software (SQL*Plus, SQL Developer) what are the single pl/sql blocks to be executed.
use slash in SQL*Plus command line when you want to execute buffered statement (yes it is a single sql statement without the semicolon or pl/sql block without the slash).
Use slash after statements that end with "end;", otherwise do not use it.
Before creating the object type in Oracle, dummy types are created to reference other types that have not yet been defined. Slash is used to executing the most recent type definition changes, or to replace the existing type in the SQL buffer with the replaced type.
References:
https://docs.oracle.com/cd/E18283_01/server.112/e16604/ch_twelve004.htm