CREATE ASSEMBLY error SQL Server 2008 R2 - sql-server

I am trying to create an assembly in SQL Server 2008 R2. I am using this below code to create the assembly.
CREATE ASSEMBLY [WRQ.Verastream.HostIntegrator]
AUTHORIZATION [dbo]
FROM 'D;\.....\WRQ.Verastream.HostIntegrator.dll'
WITH PERMISSION_SET = UNSAFE GO
But I am getting this error.
Msg 6586, Level 16, State 1, Line 1
Assembly 'WRQ.Verastream.HostIntegrator' could not be installed because existing policy would keep it from being used.

According to this article by Microsoft, Only members of the sysadmin fixed server role can create and alter UNSAFE assemblies. You will need to add your current login to the sysadmin fixed server role.
I don't have my management studio available at this time, but I believe this will work:
USE YOURDATABASENAME
GO
EXEC sp_addsrvrolemember 'YOURUSERNAME', 'sysadmin';

Run the following command:
select * from sys.fn_my_permissions(NULL, 'SERVER')
where permission_name like '%ASSEMBLY%'
You're looking to see if you have either "external access assembly" or "unsafe assembly" (you'll likely need the latter). Also check to make sure that CLR is enabled at the server level with the following:
select value_in_use from sys.configurations where name = 'clr enabled'
If that doesn't return 1, CLR flat out won't run.

Related

SQL Server OPENROWSET without SYSADMIN role

We extensively use the OPENROWSET function to import .CSV and Excel files into our SQL Server 2012 environment, using MSDASQL or ACE:
SELECT *
FROM OPENROWSET ('MSDASQL',
'DRIVER={MICROSOFT access TEXT DRIVER (*.TXT, *.CSV)};',
'SELECT * FROM E:\INCOMING\REPORT_EXTRACT.CSV')
Or using ACE:
SELECT * FROM OPENROWSET('MICROSOFT.ACE.OLEDB.12.0','TEXT;DATABASE=E:\INCOMING\;HDR=YES;', 'SELECT * FROM [REPORT_EXTRACT.CSV]');
We're experiencing the classic error message:
Msg 7415, Level 16, State 1, Line 1
Ad hoc access to OLE DB provider 'MSDASQL' has been denied. You must access this provider through a linked server.
The ONLY workaround to enable this, is granting said user(s) with the SYSADMIN role - obviously not ideal.
The location of the file(s) is on the server itself, for which the users accessing DO have the necessary permissions to access that file folder. The SQL Server service is running under the local system account with permission to interact with the desktop.
We've tried the following workarounds/fixes to no avail:
1 Executed the following code:
EXEC master . dbo. sp_MSset_oledb_prop N’Microsoft.ACE.OLEDB.12.0′ , N’AllowInProcess’ , 1
GO
EXEC master . dbo. sp_MSset_oledb_prop N’Microsoft.ACE.OLEDB.12.0′ , N’DynamicParameters’ , 1
GO
*2 The DisAllowAdHocAccess registry fix:
This is the current state:
3 Adding the ADMINISTER BULK OPERATIONS permission to the said users
We have dozens of expressions and files within our procedures that use OPENROWSET, therefore BULK INSERT, building SSIS packages, leverage Excel files as linked servers are NOT feasible options.
Any suggestions?
Wow - After YEARS of troubleshooting, I finally figured out what it was!
The registry entry value that controls the Allowing of Ad-hoc access, relies on the DisallowAdHocAccess being in that EXACT sentence case.
In our case, the "A" in AdHoc was not capitalized:
To fix this, I:
Deleted the registry value as described
Re-enabled the Disallow AdHoc Access option (Which re-created the registry value)
Manually set the Registry DisallowAdHocAccess value to "0"
Problem solved!

Run different liquibase scripts based on SQL Server version

I am trying to use liquibase to add members to a role, but the SQL is different from SQL Server 2008 to 2012.
SQL Server 2008:
exec sp_addrolemember db_datareader, MYUSER
SQL Server 2012:
ALTER ROLE db_datawriter ADD MEMBER MYUSER
The following SQL when run via liquibase against SQL Server 2012 works correctly, but when ran against SQL Server 2008 it fails and says:
Incorrect syntax near the keyword 'ADD'
Code:
DECLARE #ver nvarchar(50),
#intVer int,
#ver2008 int = 10
SET #ver = CAST(serverproperty('ProductVersion') AS nvarchar)
SET #intVer = CAST(SUBSTRING(#ver, 1, CHARINDEX('.', #ver) - 1) AS int)
IF (#intVer = #ver2008)
exec sp_addrolemember db_datawriter, MYUSER
ELSE
ALTER ROLE db_datawriter ADD MEMBER MYUSER;
I tried separating the versions, putting SQL Server 2008 in one file and 2012 in another and using a 'precondition' at the top of the changelog (outside of a changeset). But there are only 2 OnFail options, HALT, which stops the entire update, or WARN, which just continues the script, both of which do not give me what I need.
I need to be able for the script to figure out which version of SQL Server it is working with and only run that particular liquibase script, whether it be a changeset or changelog.
The compilation of the entire batch will fail if the syntax is unrecognized. You can work around the issue by wrapping the statements in EXECUTE or by using sp_executesql.
IF (#intVer = #ver2008)
EXECUTE(N'exec sp_addrolemember db_datawriter, MYUSER;')
ELSE
EXECUTE(N'ALTER ROLE db_datawriter ADD MEMBER MYUSER;');

Cannot get Linked Servers to work in Sql Azure

We are using a trial version of Azure. We are trying to perform cross server queries from our SQL Server 2012 in-house.
We seem to have our local 2012 linked with Azure. When I go into Server Object -> Linked Servers in management studio, I see our Azure database.
But if I try to open the catalog and tables, I get an error message saying
Reference to database and/or server name in 'Perseus.sys.sp_tables_rowset2' is not supported in this version of SQL Server
** Perseus is the name of our catalog in Azure Sql.
Running a query from local connection:
SELECT * FROM [azureDBServer].[Perseus].[dbo].[accounts]
Tesult is:
OLE DB provider "SQLNCLI11" for linked server "azureDBServer" returned message
"Unspecified error". Msg 40515, Level 16, State 2, Line 1 Reference to database and/or
server name in 'Perseus.sys.sp_tables_info_90_rowset' is not supported in this version of
SQL Server.
This same in house SQL 2012 Server is able to connect to our in-house 2008 by cross server queries and by viewing its structure through Linked Servers.
I know from this article Azure supports Linked Servers.
So I'm lost about what is wrong. Our Admin thinks it may be that we have a Web-Sql account vs a business SQL account. This Azure Web vs Business SQL outdated Stack link implies that SQL version is NOT the problem, but pre-dates when Azure offered Linked Servers.
So, I'm trying to understand if
a) we didn't set up something right to provide SQL Linking?
b) we are limited by trial?
c) are we limited by Web SQL version?
d) anything else?
Need to execute below mentioned three stored procedures to add SQL Azure. Using below these stored procedure I was able to query SQL azure.
EXEC sp_addlinkedserver
#server='PROD',
#srvproduct='',
#provider='sqlncli',
#datasrc='azureserver.database.windows.net',
#location='',
#provstr='',
#catalog='database name'
EXEC sp_addlinkedsrvlogin
#rmtsrvname = 'PROD',
#useself = 'false',
#rmtuser = 'Azure login',
#rmtpassword = 'password'
EXEC sp_serveroption 'PROD', 'rpc out', true
While adding linked server from SQL Management, you are not given option to set default database. So use something like below
EXEC sp_addlinkedserver
#server='name for referring locally', -- here you can specify the name of the linked server
#srvproduct='',
#provider='sqlncli', -- using SQL Server native client
#datasrc='AzureMachineName.database.windows.net', -- add here your server name
#location='',
#provstr='',
#catalog='yourdatabasename'
I figured this works.
Did you actually setup connection to perseus database? By looking at the error message your are sending a query with 3 part or 4 part name to Azure which doesn't work as is in Azure. Please check your query and set it to use 2 part name and only three part name if it is connecting to the same database
This works for me:
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'mypassword';
CREATE DATABASE SCOPED CREDENTIAL MySecurity
WITH IDENTITY = 'mylogin',
SECRET = 'mypassword';
CREATE EXTERNAL DATA SOURCE MyDbAccess
WITH (
TYPE=RDBMS,
LOCATION='server name',
DATABASE_NAME='db_name',
CREDENTIAL= MySecurity);
CREATE EXTERNAL TABLE MyExtTable (
[Id] [int] NOT NULL,
[Name] [varchar(20)] NULL)
WITH
(DATA_SOURCE = MyDbAccess);
After that you can just use it:
SELECT * FROM MyExtTable
I got this error and my issue ended up being a type in the database name SERVER.Database.dbo.tableName.

ALTER DATABASE returning Major Error 0x80040E14, Minor Error 25501

I am attempting to recreate a SQL Server Compact database from a script. I started off creating it like this:
CREATE DATABASE [MyDatabase]
GO
and that seemed to work. The next commands in the script are these:
ALTER DATABASE [MyDatabase] SET ANSI_NULL_DEFAULT OFF
GO
and about two dozen similar commands. I have tried a representative sample of these and they all return the error:
Major Error 0x80040E14, Minor Error 25501
ALTER DATABASE [MyDatabase] SET ANSI_NULLS OFF
There was an error parsing the query. [ Token line number = 1,Token line offset = 7,Token in error = DATABASE ]
Does anyone know what the matter is?
I'm using Microsoft SQL Server Management Studio 2008 R2 on Windows XP.
If you check here - http://msdn.microsoft.com/en-US/library/ms174454(v=sql.90).aspx, I don't think you can do alter database in SQL Server CE.

FileStream doesn't seem to get enabled

On one of our Dev DBs I am trying to enable FileStream.
I ran the script below and it is says it went from 0 - Disabled to 2 - Enabled:
Use FileStreamTest
GO
EXEC sp_configure 'filestream access level', 2
GO
RECONFIGURE
GO
But When I run this I get the error FILESTREAM is disabled?:
ALTER DATABASE FileStreamTest
ADD FILEGROUP FS_FG_20110101
CONTAINS FILESTREAM
GO
Running this Shows a value of 2 (Enabled):
SELECT * FROM sys.configurations
WHERE name = 'filestream access level';
Error Message:
Msg 5591, Level 16, State 3, Line 1
FILESTREAM feature is disabled.
Any ideas what I am doing wrong?
EDIT:
Do I have to go into the SQL Server Configuration manager and change the properties on the MSSQLSERVER instance (service) as well?
Yes, you do need to enable file stream through SQL Server Configuration Manager. Here is some more information.
On SQL Server 2008 R2 it is necessary to restart the SQL server service after the reconfiguration even when you execute RECONFIGURE or RECONFIGURE WITH OVERRIDE.
Proof:
SELECT * FROM sys.configurations WHERE name = 'filestream access level';
returns the value for configuration setting 1580 "filestream access level" as 2 but value_in_use 1.
After a restart of the service, the problem goes away and there is one obstacle less on the winding road of FILESTREAM configuration.

Resources