I was using this option for a long time on specific query, all of the sudden SQL Server throws this error:
Msg 8622, Level 16, State 1, Line 2
Query processor could not produce a query plan because of the hints defined in this query. Resubmit the query without specifying any hints and without using SET FORCEPLAN.
What could be the reason for this error to be generated at this moment if nothing was changed in the stored procedure? I know is not recommended to used I just want to know why is working in one server but not in another?
Related
I'm having issues using Visual Studio 2019 to publish a database project to a target server where the database does not yet exist. During the publish process, the following error happens:
(46075,1): SQL72014: .Net SqlClient Data Provider: Msg 8623, Level 16, State 1, Line 14 The query processor ran out of internal resources and could not produce a query plan. This is a rare event and only expected for extremely complex queries or queries that reference a very large number of tables or partitions. Please simplify the query. If you believe you have received this message in error, contact Customer Support Services for more information.
(46062,0): SQL72045: Script execution error. The executed script:
The error does not appear to be related to specific SQL as the error message would suggest. If I comment out a script that generates the error, the error shows up in the next script in the sequence. Overall, the publish script produced by VS2019 is approximately 72k lines. The error pops up after approximately 46k lines.
EDIT:
Server details:
SQL Server 2019 Developer edition (15.0.2000.5). 4 processors, 16 gb memory
This was my system having the problem that Anthony posted about for me. We've now figured out the cause. The root cause was a post deployment script to populate a table with initial values. The script uses a reasonably complex merge statement and tried to insert about 18,500 rows of data.
We were thrown off initially because the error output pointed to a different script in the set, not the one causing a problem. Evidently just what was in the error buffer when it burped.
Why this returns error:
DROP VIEW vTest; GO
Msg 102, Level 15, State 1, Line 1
Incorrect syntax near 'GO'.
And this works fine:
DROP VIEW vTest;
GO
And how to adjust first statement so that it runs fine on the same line?
If you're passing SQL to SQL Server via an API, you do not need the "GO". The "GO" is a feature of OSQL.exe, ISQL.exe, SQLCMD.exe, and SQL Server Management Studio. It's not a feature of SQL Server or T-SQL. So if you're coding in C# or javascript or Ruby or Perl or whatever, and you're just trying to execute some SQL via an API... just pass the SQL, no "GO" commands, and it'll work for you.
The "GO" is just a "batch separator", separating batches of SQL to be sent to SQL Server. It's utterly unnecessary here, when you have only one batch.
Running this SQL from a SQL Server Agent Job:
delete p
from sometable p
join sometable_deletes src on src.primarykeyid = p.primarykeyid
But I get this error:
Error: 8624, Severity: 16, State: 116.
Internal Query Processor Error: The query processor could not produce a query plan. For more information, contact Customer Support Services.
The SQL runs fine directly in SQL Server Management Studio. Also, from a SQL Server Agent Job, I can run a similarly structured delete statement fine with different tables. But there is something wrong with this particular statement.
How can I figure out what the actual issue is here? Or get more error info?
I have no idea why, but adding this to the top of the SQL in the SQL Server Agent Job resolved the issue for me:
set QUOTED_IDENTIFIER ON
I am using the free azure websites and made an sql database. I need to create the db tables, and then insert the dummy in.
I tried to generate the scripts through sql management studio but I get a lot of errors when I run it against the azure db.
Msg 40508, Level 16, State 1, Line 1
USE statement is not supported to switch between databases. Use a new connection to connect to a different Database.
Msg 102, Level 15, State 1, Line 5
Incorrect syntax near 'CONTAINMENT'.
Msg 102, Level 15, State 1, Line 11
Incorrect syntax near 'COMPATIBILITY_LEVEL'.
How can I get the data into my azure database?
Just taking a guess here, based on the errors: When generating scripts via SSMS, you need to specify output specific to Windows Azure SQL Database (formerly known as SQL Azure). I don't have it installed at the moment so I can't provide you with a screenshot. I'll update my answer, should I get it installed before you verify this is indeed the issue.
as David mentioned above, you can specify the script generation to target Windows Azure SQL Database
Hi this may be a little late but I found the this link to be helpful:
You basically have to manualy change the context (click on the correct database on the list of dropdown) before executing the query. You may have noticed this when working between databases.
Hope this helps
I got this error when trying to run a query in SQL server query analyzer.
What is the reason?
If you're using cursors, then you've probably closed the cursor. Check out MSDN for more information (http://support.microsoft.com/kb/151693)
If you're not using cursors, then it could be an issue with the server, check the log.
And before it's lost to the sands of time, the KB article:
Article ID: 151693 - Last Review: October 3, 2003 - Revision: 3.0
FIX: Err Msg "Unknown Token Received from SQL Server"
Symptoms
When you set the statement options to use a server-side cursor and prepare a select statement on a SQL Server system table, the first execution of the select creates the cursor successfully. After you close this cursor, if you execute the prepared statement again, the following error message appears:
unknown token received from SQL Server.
Workaround
Use a forward-only cursor instead of a static, keyset, or dynamic cursor on the system tables. Note that the problem does not occur if a server-side cursor is created on a user-defined table or view.
If a forward-only cursor is unacceptable, prepare the select statement again on the system table and execute it to create a server-side cursor. Note that the first execution works fine and applications typically do not need to create a cursor on a system table repeatedly.
Status
Microsoft has confirmed this to be a problem in Microsoft SQL Server version 6.50.0201. This problem has been corrected in U.S. Service Pack 1 for Microsoft SQL Server version 6.5. For more information, contact your primary support provider.