March 14, 2013 at 10:37 am
Any idea on this...
Msg 8624, Level 16, State 21, Line 1
Internal Query Processor Error: The query processor could not produce a query plan. For more information, contact Customer Support Services.
we are on SQL Server 2008 R2.
Thanks
March 14, 2013 at 10:52 am
Admingod (3/14/2013)
Any idea on this...Msg 8624, Level 16, State 21, Line 1
Internal Query Processor Error: The query processor could not produce a query plan. For more information, contact Customer Support Services.
we are on SQL Server 2008 R2.
Thanks
Sorry, but I can't see what you see.
March 14, 2013 at 10:59 am
What build are you on?
SELECT SERVERPROPERTY('Edition') AS Edition,
SERVERPROPERTY('ProductVersion') AS ProductVersion,
SERVERPROPERTY('ProductLevel') AS ProductLevel
Can you please post the query as well?
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
March 14, 2013 at 11:22 am
Enterprise Edition (64-bit)10.50.1777.0RTM
give me your email id i can send to you..
Thanks
March 14, 2013 at 11:25 am
Admingod (3/14/2013)
Enterprise Edition (64-bit)10.50.1777.0RTMgive me your email id i can send to you..
Thanks
If you can't post the query here, don't bother emailing or PMing me.
March 14, 2013 at 1:00 pm
March 14, 2013 at 1:15 pm
harsha.majety (3/14/2013)
Microsoft conect entry
Having read the connect item, looks like you need to install a service pack and/or some CU's and then enable the trace flag 4199.
November 1, 2013 at 11:34 am
We are running SQL SERVER 2008 R2 STD 10.50.4295 which is the most recent build and we can duplicate this issue on demand. the only workaround we have found is to set the two ANSI settings on (ansi_warnings and ansi_padding) for the connection. We tried setting these within the procedure and outside the procedure with no luck. I have updated the connect item posted earlier, however, it being closed not sure that MSFT will see it.
November 1, 2013 at 10:46 pm
November 2, 2013 at 10:00 am
the query is just an single update statement. There are four update triggers on this table, with nested stored procedures, not to mention all the FK references.
We cannot script out this database and post it on a public forum due to the fact that 1. it is a third party vendor and 2. this database supports a trading system.
I just wanted to mention that applying the latest CU and using trace flag 4199 does not help. We have a case opened with MSFT. If we find a resolution I will post back.
Thanks for reaching out, much appreciated.
November 12, 2014 at 4:03 pm
Does anyone have an answer for this? I strictly control all ANSI settings so that is not the issue for me. I have a similar problem with deleting a row from a table with three delete triggers, one of which is an InsteadOf delete trigger. The app works for other customers but not for this particular one and only on one of their hosts. I played around with assigning first/last firing order to no avail. I'm working on having the customer install the latest service pack for 2008R2 for that particular host.
I have gotten this Internal Query Processor Error several times before in development by writing a SELECT with a correlated subquery using one style and resolving the error by using a different style but equivalent resultset.
April 9, 2015 at 3:07 pm
I was getting the same error, but strangely, all I did was add DISTINCT to my query and it worked. I'm not going to research why, but that might be a clue for someone else.
August 30, 2015 at 3:20 pm
I'm getting the same error on A SQL 2012 SP1 instance with a large ETL Merge statement.
Adding ORDER BY made no difference, but adding select DISTINCT seemed to get around the issue.
We also tried updating statistics for the whole db. and we use default instance settings.
Edit: We found the cause of the error. We had missed a where clause in the merge statement. Specifically the select from the source table was returning multiple rows for the given merge join fields. Once we added "and is_current = 1" to the where clause which meant it was selecting unique rows it worked.
This was failing even through there where zero records in the fact table. So we suspect that SQL was smart enough to detect that it didn't have unique rows in the source select. I hope this is of use to someone. 🙂
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply