OK, so I think I'm going mad here! Here's where I am.
SQL Server 2008: I've set up Database Mail, and I've sent myself a test email. Simple, works fine.
I've created an operator, called 'Tom'. I've given it an email address (but nothing else).
However, when I run this command:
EXECUTE msdb.dbo.sp_notify_operator #name=N'Tom',#subject=N'Test Database Message',#body=N'Testy Test Test'
...I get this:
Msg 14262, Level 16, State 1, Procedure sp_verify_operator_identifiers, Line 51
The specified #operator_name ('Tom') does not exist.
Is that error message masking something else which I should be looking at? There's definately an operator shown in SSMS, but if there's a sproc which lists operators I'll happily run that to see if it's actually there.
I'm just kinda stuck as to where to go next. SQL Server seems convinced I don't exist!
Ignore this! There's a possibility that I was trying to execute sp_notify_operator whilst connected to the wrong server...the one without any operators....
Apologies!
Related
I am training up on a bit of SQL and yesterday thought that I got the general idea of it. My script yesterday was completely working and returning the data I asked for when I asked for it - I reloaded the script today and for some reason the following error message is showing up.
"Msg 208, Level 16, State 1, Line 25
Invalid object name 'dbo.DoubleClick_Floodlight'."
I have a colleague who is also training with me and despite us having to 2 same scripts my one won't load and hers will - She also emailed me over her script so I could copy and paste it in and implement i on my computer but still no luck.
I have also tried dragging over the table name into my script to ensure it matches but the following error is still presented - I've attached screenshots of the script..
The problem will be one of:
you are connected to the wrong database (see the database drop down in the top left hand corner of SSMS). Check that it matches the database you are expecting to connect to. (Ctrl+U will take you to this drop down).
the object no longer exists within the database. If the above is correct, have a look in the Object explorer to see if you can still see the object there - again check that you're looking under the correct database in the tree.
you no longer have permissions on the object.
Very often extremely trival edits cause my T-SQL scripts to fail when rerun from within a MS SQL Server 2012 edit window (e.g. "SqlQuery1.txt"). Frustratingly, there's no pattern to what (edits) cause this problem. Coping with this has forced me to jump through some wierd hoops.
An example: I changed exactly 1 character in a working query (from "Set #THisColumn = 1" to "Set #ThisColumn = 1"; the "H" was changed to "h'" to match the variable declaration). When the script was rerun MS SQL Server 2012 gave me this error:
Msg 213, Level 16, State 1, Line 54
Column name or number of supplied values does not match table definition.
My research shows this message gets thrown when there is a problem with a TABLE which should be impossible in the above case. The error is unimportant, my problem is much more general - having to use the following unsatisfactory "workaround":*
Copy the (edited) script into a new edit pane ("SQLQuery2.txt"). It works - until the next time it's edited. Which then forces me to use another edit pane ("SQLQuery3.txt"). Repeat ad nausum.
Having to do this supports the theory that the problem is somehow related to how the edit pane works - NOT the script. (Hence the title of this question)
Using this "workaround" destroys my train of thought while the resulting large number of open "scratchpad" windows causes me to lose track of what I was doing ("... lets see now, is it version 13, 17, 26 or 28 that is the last "known good" version?...).
My suspicion is that SQL considers every subsequent rerun as being a part (a continuation) of the FIRST invocation of that script. So it tries to be "helpful" (not!) by "optimizing" the query.
In a development environment this "assistance" is very premature - and exactly what I do NOT want to have happen. (First make it work...then optimize it.) How do I supress this undesirable behavoir?
From my research I know that my scripts must have lines like this one before creating a temporary table:
IF OBJECT_ID( 'tempdb..#XYZ) IS NOT NULL DROP TABLE #XYZ
and for a temporary procedure:
IF OBJECT_ID( 'tempdb..#ABCD) IS NOT NULL DROP PROCEDURE #ABCD
GO -- Required before defining any procedure
CREATE PROCEDURE #ABCD
The need to do this implies that my supposition may be correct (why else would you need to do it?).
What else has to be done so that every time I press the "execute" button I get a "clean restart" of SQL?
Other factors to keep in mind:
The script, invoked from Python 3.x, is periodically (and
frequently) run as batch/cron job (i.e. an automatically scheduled
task). This means that any form of manual intervention (e.g. using
tools like MS 2012 Management Studio etc.) is not an option.
Stored procedures aren't allowed, instead the python application reads a file of SQL commands that get passed to SQL for execution
(in effect emulating a user who types in those commands at a SQL
console).
Finally the script must also work for users that have the minimum
possible (e.g "guest") privileges
.
This is my PHP SQL statement and it's returning false while var dumping
$sql = $dbh->prepare('INSERT INTO users(full_name, e_mail, username, password) VALUES (:fullname, :email, :username, :password)');
$result = $sql->execute(array(
':fullname' => $_GET['fullname'],
':email' => $_GET['email'],
':username' => $_GET['username'],
':password' => $password_hash));
TL;DR
Always have set PDO::ATTR_ERRMODE to PDO::ERRMODE_EXCEPTION in your PDO connection code. It will let the database tell you what the actual problem is, be it with query, server, database or whatever. Also, make sure you can see PHP errors in general.
Always replace every PHP variable in the SQL query with a question mark, and execute the query using prepared statement. It will help to avoid syntax errors of all sorts.
Explanation
Sometimes your PDO code produces an error like Call to a member function execute() or similar. Or even without any error but the query doesn't work all the same. It means that your query failed to execute.
Every time a query fails, MySQL has an error message that explains the reason. Unfortunately, by default such errors are not transferred to PHP, and all you have is a silence or a cryptic error message mentioned above. Hence it is very important to configure PHP and PDO to report you MySQL errors. And once you get the error message, it will be a no-brainer to fix the issue.
In order to get the detailed information about the problem, either put the following line in your code right after connect
$dbh->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION );
(where $dbh is the name of your PDO instance variable) or - better - add this parameter as a connection option. After that all database errors will be translated into PDO exceptions which, if left alone, would act just as regular PHP errors.
After getting the error message, you have to read and comprehend it. It sounds too obvious, but learners often overlook the meaning of the error message. Yet most of time it explains the problem pretty straightforward:
Say, if it says that a particular table doesn't exist, you have to check spelling, typos, letter case. Also you have to make sure that your PHP script connects to a correct database
Or, if it says there is an error in the SQL syntax, then you have to examine your SQL. And the problem spot is right before the query part cited in the error message.
You have to also trust the error message. If it says that number of tokens doesn't match the number of bound variables then it is so. Same goes for absent tables or columns. Given the choice, whether it's your own mistake or the error message is wrong, always stick to the former. Again it sounds condescending, but hundreds of questions on this very site prove this advice extremely useful.
Note that in order to see PDO errors, you have to be able to see PHP errors in general. To do so, you have to configure PHP depends on the site environment:
on a development server it is very handy to have errors right on the screen, for which displaying errors have to be turned on:
error_reporting(E_ALL);
ini_set('display_errors',1);
while on a live site, all errors have to be logged, but never shown to the client. For this, configure PHP this way:
error_reporting(E_ALL);
ini_set('display_errors', 0);
ini_set('log_errors', 1);
Note that error_reporting should be set to E_ALL all the time.
Also note that despite the common delusion, no try-catch have to be used for the error reporting. PHP will report you PDO errors already, and in a way better form. An uncaught exception is very good for development, yet if you want to show a customized error page, still don't use try catch for this, but just set a custom error handler. In a nutshell, you don't have to treat PDO errors as something special but regard them as any other error in your code.
P.S.
Sometimes there is no error but no results either. Then it means, there is no data to match your criteria. So you have to admit this fact, even if you can swear the data and the criteria are all right. They are not. You have to check them again. I've short answer that would help you to pinpoint the matching issue, Having issue with matching rows in the database using PDO. Just follow this instruction, and the linked tutorial step by step and either have your problem solved or have an answerable question for Stack Overflow.
Some time ago I had the same problem of not seeing any error messages from mysql. After a research it turned out that the problem has got nothing to do with PHP itself, but with mysql server configuration. The default value of the variable lc_messages_dir pointed to non existing directory. After adding a line in mysqld.cnf, then restarted the mysql server, and finally I was able to see the error messages. For me the following was the right one:
lc_messages_dir=/usr/share/mysql
It is described in the mysql reference manual: https://dev.mysql.com/doc/refman/5.7/en/error-message-language.html
I created a Sybase database emp_details using SQL Anywhere and Sybase Central. I had given emp/emp as dba username/password while creating.
The db got created and the files were generated in the given folder.
When I tried running the below script using Ineractive SQL:
use master
go
if exists (select 1 from master..sysdatabases where name='emp_details')
checkpoint emp_details
go
It threw the following exception
Could not execute statement.
Syntax error near 'checkpoint' on line 2
SQLCODE=-131, ODBC 3 State="42000"
Line 4, column 1
Haven't been able to figure out what exactly the syntax issue is and have been stuck up with this for a while.
Any ideas?
First of all, you may want to think about posting your SQL Anywhere questions to the http://sqlanywhere-forum.sap.com/ forum. It's a forum dedicated to the SQL Anywhere product line.
Is there any possibility that the two periods together might be causing your syntax issue?
Normally you're not going to get an exact area where the error is coming from. See if that helps. Also check out the other forum as well.
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.