I have a nightly job which is updates table by executing stored procedure but it keeps failing every 2-3 days.
DECLARE #return_value int
EXEC #return_value = [dbo].[sp_SRA_Analysis_Union]
SELECT 'Return Value' = #return_value
Below is the error message:
Step Name update table
Duration 00:00:30
Sql Severity 16
Sql Message ID 7359
Operator Emailed
Operator Net sent
Operator Paged
Retries Attempted 0
Message
Executed as user: NT AUTHORITY\SYSTEM.
The OLE DB provider "SQLNCLI10" for linked server "SQL05"
reported a change in schema version between
compile time ("182390105529348") and
run time ("182402990418943") for table "dbo"."CL_Midpoint"".
[SQLSTATE 42000] (Error 7359). The step failed.
Any idea/suggestions how to avoid this?
Thanks,
AR
Got the exact same error today. Did some research and found this: https://support.microsoft.com/en-us/kb/2498818
It appears to be a bug while using a linked server and synonym/aliases and/or views that refer to the linked server. In our case we had a linked server from SQL Server 2014 to SQL Server 2008R2. A reindex operation was run on a table that was being accessed using linked server (and the query was using a table alias for the linked server asset), we got this error.
Two things worked for me:
1. Just re-ran the SP and it worked fine.
2. Removed the table alias in the SP query and that resolved the issue for future too.
Got it fixed with following sql query inside problem db:
DBCC FREEPROCCACHE WITH NO_INFOMSGS;
where you delete the cache for the query that is causing the issue.
Related
Please help me out with the solution.
When i try to execute the Update Command, I am getting the following error. I am using SQL Server 2012.
UPDATE WorkOrder SET Delivered = GETDATE() WHERE WONumber= 69375
Error: Internal Query Processor Error: The query processor encountered an unexpected error during execution (HRESULT = 0x80040e19)
In my issue with the same error, while running a DBCC checkdb command through SQL, I found issues with a few Tables.
I had to place the database in Single_User Mode,
run the – DBCC CHECKDB (‘xxxx’,REPAIR_REBUILD); –
(note: the ‘xxxx’ is the database name),
then place the database back in Multi_User Mode.
This resolved the issue for my Client.
I am using SQL Server 2014. I have created the following T-SQL query which I uploaded to my local SQL server to run as a job process on a daily basis at a specific time. However, I noticed that it failed to run. If I run it manually in SSMS, it runs correctly.
What is preventing the query to run as an automated process? Is it a syntax issue?
USE MyDatabase
GO
DELETE FROM ExchangeRate -- STEP 1
;WITH MAINQUERY_CTE AS ( --STEP 2
SELECT *
FROM (
SELECT *
FROM [178.25.0.20].HMS_ARL.dbo.ExchangeRate
) q
)
INSERT INTO ExchangeRate --STEP 3
SELECT *
FROM MAINQUERY_CTE
Basically, the function of the query is to copy a table named ExchangeRate from the live server and paste its content in a table of the same name (which already exists on my local server).
Error Log shows the following message:
Description: Executing the query "USE MyDatabase DELETE FROM
ExchangeRate..." failed with the following error: "Access to the
remote server is denied because no login-mapping exists.". Possible
failure reasons: Problems with the query, "ResultSet" property not set
correctly, parameters not set correctly, or connection not established
correctly. End Error DTExec: The package execution returned
DTSER_FAILURE (1). Started: 10:59:30 AM Finished: 10:59:30 AM
Elapsed: 0.422 seconds. The package execution failed. NOTE: The
step was retried the requested number of times (3) without succeeding.
The step failed.
May be you have to create Linked Server in your local server to the Remote server?
this statments work under V6R1 but not under V7R1 with an ODBC linked server in an SQL Server 2012
select * from AS400.AS400.LIB.TAB
SQL Managment Studio thrown the error:
Cannot process the object "AS400.LIB.TAB". The OLE DB provider "IBMDASQL" for linked server "AS400" indicates that either the object has no columns or the current user does not have permissions on that object. [SQLSTATE 42000] (Error 7357). The step failed.
Do somebody have an idea to fix this problem?
regards Jo
EXEC ('SELECT * FROM LIB.TAB') AT AS400
and if calling a stored procedure that returns data:
EXEC ('{CALL LIB.SP_TEST(?,?,?)}', 'Data', 'Data2', 'Data3') at AS400
i found a solution
select * from OPENQUERY(AS400,'SELECT * FROM LIB.TAB')
FWIW, I was getting this same error message along with a SQL7008 error code returned from the AS/400 whenever my code attempted to execute an UPDATE statement. While investigating, I found this article, http://www-01.ibm.com/support/docview.wss?uid=swg21007161, which led me to discover that journaling had been turned off earlier for the table in question due to scheduled upgrade to our ERP system and was never turned back on afterwards. Once journaling was turned back on, my updates began working again.
I have created a linked server in SQL Server 2005 to an Oracle DB. When I run a query, The query never stops executing, and never returns results. When I cancel the query, it never completes cancelling. I have to close the window to get it to stop.
I have set things up as follows:
Installed Oracle Client Tools on SQL Server
Ran following query:
EXEC sp_addlinkedserver
#server = 'MyNewLinkedServer',
#srvproduct = 'Oracle',
#provider = 'OraOLEDB.Oracle',
#datasrc = 'TNSNAMES_Entry'
I then added the TNSNAMES.ORA file to ORAHOME1\network\admin\ directory.
In Properties for my Linked Server, I changed the Security settings to Be made using this security context: for all connections using my Oracle username/password
I ran the following query:
SELECT * FROM OPENQUERY(MyNewLinkedServer, 'SELECT COUNT(*) FROM MySchema.MyTable');
The query never completes execution. Anyone have any insights? Any steps I'm missing?
UPDATE:
I came in the following day and tried the query again and it worked just fine. I suspect network issues of some sort.
Look on the Oracle server, querying v$session. See if you can see the remote connection, and what the Oracle session is doing. You can even do a trace on the Oracle side (set off by a login trigger) to record everything that happens (eg parse of query, returned errors etc).
We have 2 databases, say DB1 and DB2.
DB1 contains all the stored procedures which access also data in DB2.
DB1 uses synonyms to access the tables in DB2.
(Using synonyms is a requirement in our situation)
This works perfectly fine in all situations with SQL Server 2005 Developer Edition.
However in the Express Edition, we get an exception when we do the following:
1 Restart SQL Server
2 Execute the following code within DB1:
set transaction isolation level snapshot
begin transaction
declare #sQuery varchar(max)
set #sQuery = 'Select * from synToSomeTableInDB2'
exec (#sQuery)
commit transaction
This will result in the following error:
Snapshot isolation transaction failed in database '...' because the database was not recovered when the current transaction was started. Retry the transaction after the database has recovered.
The same select query passes fine when used without the EXEC or when run on the Developer Edition.
Restarting the server in step 1 is important as once a connection was made to DB2, the code runs also fine on SQL Server Express Edition.
Does anyone have an idea what this is? We need to be able to use EXEC for some dynamic queries.
We've already checked MSDN, searched Google, ...
Any help is greatly appreciated.
--- Edit: March 10 09
As discussed with Ed Harper below, I've filed a bug report for this.
See https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=422150
As found out via Microsoft Connect, the problem is that by default on SQL Server Express Edition the AUTO_CLOSE option is set on true.
Changing this option to false fixes the problem.
The error message suggests that the query fails because SQL server is still recovering the database following the service restart when you execute your query.
Does the error always occur on the first attempt to run this code, regardless of the time elapsed since the service was restarted?
Can you confirm from the SQL Server log that the database is recovering correctly after the restart?