I'm not able to see the messages added to dbms_output.put_line() in PL/SQL Developer. Every google hit I see says to use set serveroutput on but this isn't working.
I try to run this script in a SQL Window:
set serveroutput on;
BEGIN
dbms_output.put_line('hello')
END
But I get an error on the set serveroutput on line:
And I get no output in the Output tab (regardless of whether I have the set serveroutput on):
How can I see the output sent to dbms_output.put_line('hello') in a script run in an SQL Window?
Thank you.
That is because in PL/SQL Developer, a SQL Window can only contain either SQL or PL/SQL blocks. There is a checkbox for enabling or disabling dbms_output. SQL windows aren't really for scripts, unless the 'script' is a set of SQL queries or PL/SQL blocks and nothing else.
(If there is more than one statement in the window, it may be helpful to add / as a terminator after the PL/SQL block, otherwise PL/SQL Developer won't know where one statement ends and the next begins unless you explicitly highlight it with the mouse.)
Alternatively, you could use set serverout on in a Command window (which is a SQL*Plus emulator), or better, use a Test window, which is specifically designed for executing PL/SQL blocks.
Related
I am calling IF (0 = FULLTEXTSERVICEPROPERTY('IsFullTextInstalled')) RETURN; at the beginning of my full text search stored procedure. This should force the stored procedure to exit if full text search is not installed.
However I keep getting the typical Full-Text Search is not installed, or a full-text component cannot be loaded error message.
Any ideas?
Ok. It turns out that FULLTEXTSERVICEPROPERTY('IsFullTextInstalled') returns a different value based on the context to which is it executed.
In my case it returned 0 within a query executed via SQL Management studio and 1 from within my stored procedure.
The correct code to use is DATABASEPROPERTY(DB_NAME(), 'IsFulltextEnabled') which returns a consistent result regardless of the context.
I'm executing sql scripts while using ADO and MSSQL server .
Under Here you will find an first example of a multi lines sql statement like :
use master;
go;
EXEC sp_detach_db
#dbname=N'DATABASENAME';
go;
I copy these lines from a Tmemo to my TADOQuery.sql.text but fail as already the go statement is not recognized and I get a keyword error by the mssql server.
Can I run the whole sript as one TQquery or do I have th split my query into several pieces, separated by the semicolon and iterate through the whole text ?
At first your code is not valid (no ; after GO) and has to be like this
USE master;
GO
EXEC sp_detach_db
#dbname=N'DATABASENAME';
GO
In fact GO is a delimiter used by MSSMS to separate the SQL-Statements.
If you want to use the same scripts as MSSMS do, you have to work on that like MSSMS.
Split the script into single parts by delimiter GO
Send every part to the Database
You have to split every statement whithout sending go.
SQL-Server is not interpreting GO, this is done by MSSMS.
I'm still relatively new to SQL Server but love a lot of things about it, except for the array of "all-slightly-different-but-none-can-do-everything", "finicky-in-different-ways" scripting options where, just when you feel like you're starting to get a handle on things and are cruising, you slam into yet another roadblock. I've been down the dynamic SQL path (and have found the restrictions on variables having short lifetimes) and as per a previous suggestion that I received ( Script to create a schema using a variable ), am now trying to write sqlcmd scripts instead.
A lot of scripts work fine and dandy if you run them "naked". As soon as you put some of them into a Try / Catch block to implement error handling on them, however, you often run into ridiculous restrictions most notably DDL commands which "vant to be alone" and need to be the first/only statement in a batch. Go is useless in this context because if you put THAT anywhere inside a Try/Catch block it guarantees that you'll get a syntax error.
Obviously I've scoured the web on this (and have looked at some of the "similar questions" that appeared while editing this post) but keep coming up with examples which are either "naked" in the sense above, or are Try/Catch examples on code which doesn't have these restrictions.
In the case of creating a schema, I used the approach that had been suggested to me for dynamic SQL; I ran it through sp_executesql. That's not a problem since it's essentially one line of code, the problem is that I hit it again when I tried to create a trigger on a table (and am guessing that I will with some other Create commands).
CREATE TRIGGER MySchema.NoDelete
ON MySchema.MyTable
INSTEAD OF DELETE
AS
BEGIN
SET NOCOUNT ON;
RAISERROR ('Deletions are not allowed on this table', 16,1)
END
Run this by itself and it's fine. Put Begin Try before it and End Try and a Catch block after it and you get:
Msg 156, Level 15, State 1, Line 3
Incorrect syntax near the keyword 'TRIGGER'.
with a red squiggly line on BEGIN with the bogus tool tip "Incorrect syntax near Begin, expecting External".
I tried the sp_executesql path with this again but:
First, it also generated a bogus "Syntax error near $" error which is about as useful as telling me that there's some syntactical error, somewhere, between here and the planet Zargthorp" but more importantly:
Second, even if I did get it to work for a relatively trivial trigger like this one, I'm having nightmares trying to imagine packaging a complex, multi-line trigger in such a fashion but even if I DID get past that;
Third, it would make the code much more obscure and defeat one of the purposes of using scripts in the first place, that being self-documentation.
My questions therefore are:
Is Try/Catch effectively useless for commands which, for reasons best known to MS designers, need to live in isolated majesty like Create Trigger (and which aren't one-liners like Create Schema which can be neatly packaged up into sp_executesql); or
In my relative newbieness have I missed some other way of working around the kind of restriction that I've slammed into with Create Trigger?
Thanks in advance for any responses.
Migrating asp.net code (VB.net) to use functions and subroutines as parameters.
Using MS Server Management Studio to create said functions and subs.
Would like to test the functions from within MS SMS before testing them via the web page.
Here's an example. Say I have a function called "dbo.getNumber"
I'm trying to test it using the following:
USE [someDB]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
declare #value int;
select #value = dbo.getNumber;
print #value;
go
When I type F5 (to run the "query") it gives the following msg:
"The name "dbo.getNumber" is not permitted in this context. Valid expressions are constants, constant expressions, and (in some contexts) variables. Column names are not permitted."
The function dbo.getNumber was accepted just fine, btw. (It's counting records of a database that meet certain criteria.)
Hopefully you can infer from the non-working code what I am trying to do.
How can I print the value of a function (for testing purposes) from within SMS?
Correct solution as per James Johnson, below:
USE [someDB]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
declare #value int;
select #value = dbo.getNumber();
print #value;
go
Note the parens for the function invocation.
Note also: intellisense in SMS underlines dbo.getNumber() as if it were an error, but running the query with F5 works and outputs the right result.
You need to call it like this:
select #value = dbo.getNumber()
Here's my configuration:
I have a re-runnable batch script that I use to update my database.
Inside of that batch script, I have code that says the following:
If Table 'A' doesn't exist, then create Table 'A' and insert rows into it.
Later on in that batch script, I create an schemabound indexed view on that table.
And if you didn't already know, indexed views require specific client settings.
Sometimes, when I re-run the script, that is after the table has been created, SQL Server Management Studio evaluates the "insert rows" code, which is protected by the 'If this table doesn't exist' code, and yields the following error:
Msg 1934, Level 16, State 1, Line 15
INSERT failed because the following SET options have incorrect settings: 'CONCAT_NULL_YIELDS_NULL, ANSI_WARNINGS, ANSI_PADDING, ARITHABORT'. Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or filtered indexes and/or query notifications and/or XML data type methods and/or spatial index operations.
Please note: If someone were to try this INSERT statement in a vacuum, I would fully expect SSMS to generate this error.
But not when it's protected by a conditional block.
My Question:
Does the SSMS compiler evaluate all expressions, regardless of whether they will actually be executed?
Yes, it evaluates all of them,take a look at this
declare #i int
select #i =1
if #i = 1
begin
declare #i2 int
set #i2 = 5
end
else
begin
declare #i2 int
set #i2 = 5
end
Msg 134, Level 15, State 1, Line 12
The variable name '#i2' has already been declared. Variable names must be unique within a query batch or stored procedure.
Another example with temp tables is here: What is deferred name resolution and why do you need to care?
your only way out would be to wrap it inside dynamic SQL
Note that most of the settings you mention are connection-level, i.e. in case you set/change them they stay in effect unless you close the connection or explicitly change their value.
Returning to your question. The error you mention looks like runtime error, i.e. the INSERT is actually being executed. It would be better if you could show your script (omitting details, but keeping batches).
Edit: it is not SSMS compiler that evaluates SQL you try to execute - it is SQL Server. What do you meant by 'evaluate'? Is it 'execute'? When you run a batch (which is what actually is being executed by a server), SQL Server first does syntactic analysis and throws error in case it finds any syntactic error, nothing is being executed at this point of time. In case syntax is ok, the server starts executing you batch.
Again, the error you show seems to be runtime - so I guess you'd carefully watch for the conditions and track what happens (or provide us more details about 'sometimes').