OLE DB provider "SQLNCLI" for linked server ("null") returne
TobiasFrei
Posts: 4
Hello,
i have problems using sql-compare...
i tried to auto-build a script against a database with views, which have openrowset commands. Result is the following error:
OLE DB provider "SQLNCLI" for linked server ("null") returned message "No transaction is active.".
Msg 7391, Level 16, State 2, Procedure sp_refreshview, Line 1
The operation could not be performed because OLE DB provider "SQLNCLI" for linked server ("null") was unable to begin a distributed transaction.
This is the part of the generated script which is relevant. If i run the script without the "set transaction isolation level serializable", everything works fine.
What could be the solution for this puzzle?
Thanks in advance.
Tobias
code begin
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
GO
BEGIN TRANSACTION
GO
EXEC sp_refreshview N'[dbo].[view_blabla]'
GO
@TRANCOUNT>0 ROLLBACK TRANSACTION
go
code end
view_blabla uses an openrowset sql command.
i have problems using sql-compare...
i tried to auto-build a script against a database with views, which have openrowset commands. Result is the following error:
OLE DB provider "SQLNCLI" for linked server ("null") returned message "No transaction is active.".
Msg 7391, Level 16, State 2, Procedure sp_refreshview, Line 1
The operation could not be performed because OLE DB provider "SQLNCLI" for linked server ("null") was unable to begin a distributed transaction.
This is the part of the generated script which is relevant. If i run the script without the "set transaction isolation level serializable", everything works fine.
What could be the solution for this puzzle?
Thanks in advance.
Tobias
code begin
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
GO
BEGIN TRANSACTION
GO
EXEC sp_refreshview N'[dbo].[view_blabla]'
GO
@TRANCOUNT>0 ROLLBACK TRANSACTION
go
code end
view_blabla uses an openrowset sql command.
Comments
The isolation level will still prevent dirty reads and other concurrency problems but it is not quite as high as Serializable.
This page from msdn describes the different isolation levels that are available:
http://msdn.microsoft.com/en-us/library ... 80%29.aspx
In your original post you stated that you were effectively making this change as you were deleting the line in question and therefore allowing sql server to use the default level of Read Committed.
After much digging around, our DBAs pencilled it down to permissions on a specific object which you need to grant the user permission on if you are to use the SERIALIZABLE isolation level.
The EXECUTE permission was denied on the object 'sp_table_statistics2_rowset', database 'mssqlsystemresource', schema 'sys'.
Regards,
Kwex.