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.
Related
I'm hoping someone else may have encountered this and been able to resolve. I'm presently waiting for an azure support tech to help, so figured I'd reach out here in the mean-time since I couldn't find anything online...
I have a read-only database that users can query all tables without issues except for one specific table. Azure recommended solution pointed to login to user mapping issues, however, that would not allow the user to access the database which is not the case here.
There are no long running queries or open transactions and the server is more or less idle. I'm not seeing any locking or blocking either, so this is quite puzzling to me.
I can reproduce the issue with all users of all types testing with:
SELECT TOP 1 * FROM dbo.{table 1} - results in no issues
SELECT TOP 1 * FROM dbo.{table 2} - gets following error
Msg 40197, Level 20, State 200, Line 3
The service has encountered an error processing your request. Please try again. Error code 8630.
Msg 0, Level 20, State 0, Line 1
A severe error occurred on the current command. The results, if any, should be discarded.
In the end, Azure Support had me scale up and scale down the database and that has resolved the issue.
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
.
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.
I started using the system with a pre-made file called DB2.SQL. I am using this because it is what the tutorial said to use. I then edited this file and replaced the contents with my own code:
CREATE DATABASE BANKDB13 BUFFERPOOL BP0;
When I try to execute a SQL it though, I get this error:
DSNE377A INPUT DATA SET RECFM MUST BE F OR FB WTIH LRECL 80
What does this error mean and how do I correct it on the file?
I am running it with Vista TN3270 on Windows 7 over TSO, in SPUFI mode.
What I've tried so far:
When I start editing the file, I have a screen to change the defualts, and I have changed the RECORD FORMAT to F and FB as well as setting the RECORD LENGTH to 80 with no success.
EDIT:
I resolved the problem by deleting the DB2.SQL file and recreating it, and also making sure that the sizes I gave for the files were consistent with each other.
What SQL are you trying to execute on it?
The error means that the Record Format in the input data set must be either "F IXED" or "F IXED B" LOCK with a logical record length of 80.
So this is what the error means, how to correct it depends on the SQL you're running and the desired outcome.
What Tutorial is it that you refer to, do you have a link? Is this a real world problem, homework or you expanding your knowledge into mainframe DB2?
Your SQL snippet above is creating a DB, what is the INPUT DATASET file format that you are subsequently running SQL on?
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!