I'm new to docker and I love the implementation of it since
I wont suffer with auto running with SQL Server now which eat up my
precious MEMORY.
Though when trying to run a code to allow "import" data's from a "Access.mdb" file
using MS Access Database Engine but I got stuck with it..
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'Ad Hoc Distributed Queries', 1;
RECONFIGURE;
EXEC master.dbo.sp_MSset_oledb_prop N'Microsoft.ACE.OLEDB.12.0',N'AllowInProcess', 1
EXEC master.dbo.sp_MSset_oledb_prop N'Microsoft.ACE.OLEDB.12.0',N'DynamicParameters', 1
I already installed the MSAccessDatabaseEngine in my PC (not in docker) and when I ran it
the error is:
A severe error occurred on the current command. The results, if any, should be discarded.
So I think it should be installed inside the container, my question is... is there anyway around to install this one together with the SQL Server container?
Cheers!
Related
I have a SQL Server database project (sqlproj file) in which I have referenced an assembly containing a user-define aggregate function per https://learn.microsoft.com/en-us/sql/relational-databases/clr-integration-database-objects-user-defined-functions/clr-user-defined-functions?view=sql-server-2017
I was unable to deploy or use my function until I did this:
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'clr strict security', 0;
RECONFIGURE;
...and also:
EXEC sp_configure 'clr enabled' , '1';
RECONFIGURE;
Along the way, I tried signing the assembly (generated a self-signed cert in a pfx), but could not figure out how to get SQL Server to trust the certificate.
As best I understand it, what I've done is acceptable for a local development deployment, but this is not the right way to deploy to a live environment (or to push to an Azure database service).
I've seen advice which suggests deploying to an older version of SQL Server in order to extract a hash of the assembly to use in a command which will establish trust; this is not useful to me because I only have SQL Server 2017 and have no intention of installing something like 2008 just to extract a hash.
What is the sequence of steps I must perform to successfully deploy my custom assembly with my database and establish trust "the right way", and what exactly does each of those steps accomplish? Part of my problem is a lack of clarity around the need, purpose, side-effects, and "meaning" of each required step.
I can't find the 'locks' information in sp_configure.
I am using SQL Server 2016 (v13.0.5820.21).
I understand I should be able to find it on the 'Advanced' tab on the server properties, but is that normal? How can I bring up the 'locks' information in sp_configure?
Thank you for your answer..
The locks option is an advanced one, and is not shown by sp_configure by default. In order to see it, you need to enable advanced options first:
exec sp_configure 'show advanced options', 1;
go
reconfigure;
go
Then it will show up.
I have a very strange situation on SQL Server that I cannot fathom out.
Environment : SQL Server 2012 SP3 CU3 running on a 2 node Windows 2008 R2 cluster
In SQL Server Management Studio\Management\Maintenance Plans\ I am unable to create or edit existing plans.
I receive the error:
'Agent XPs' component is turned off as part of the security configuration for this server. A system administrator can enable the use of 'Agent XPs' by using sp_configure. For more information about enabling 'Agent XPs', see "Surface Area Configuration" in SQL Server Books Online. (ObjectExplorer)
Checking around that error I expected the following config was going to be required.
-- To allow advanced options to be changed.
EXEC sp_configure 'show advanced options', 1;
GO
-- To update the currently configured value for advanced options.
RECONFIGURE;
GO
-- To enable the feature.
EXEC sp_configure 'Agent XPs', 1;
GO
-- To update the currently configured value for this feature.
RECONFIGURE;
GO
However, I noticed that SQL Agent was already running so I thought I would also check existing config options for 'Agent XPs'
What was interesting was that config_value = 0, run_value = 1 where I was expecting config_value = 1, run_value = 1.
I thought I'd try the sp_configure solution to 'force' the config but when I ran it (step by step), the first RECONFIGURE statement just hung and indeed when it ran I could not even run an sp_who2 to see if it was blocking or being blocked.
The only way I could kill the RECONFIGURE was to close the query window which cancelled it. I therefore am unable to run EXEC sp_configure 'Agent XPs', 1 as the required RECONFIGURE cannot be run.
After a failover of the cluster, the config settings for 'Agent XPs'
remains at config_value = 0, run_value = 1.
Has anyone got any ideas as to how to fix it?
I stumbled across an internet post with a similar issue and that contained a nugget of information that allowed me to ultimately fix the issue.
I documented the case over at SQLServerCentral
https://www.sqlservercentral.com/Forums/1927277/SQL-Server-2012-tells-me-Agent-XPs-component-is-turned-off-but-SQL-Agent-is-running
I'm currently on a host(A), connecting to a MSSQL database on server(B).
When I do a System call, such as
EXEC xp_cmdshell 'Systeminfo' GO
from within MS SQL 2008 it always returns me system information from the client(A) I'm currently running my SQL management tool on.
Is there a possibility to run System calls that will return me information from the server(B)?
I have since asking this question rebooted, and tried all the steps again:
1. Turn off local server
2. Connect to external server
3. Turn on XP_CMDSHELL command for the external server using
-- To allow advanced options to be changed.
EXEC sp_configure 'show advanced options', 1;
GO
-- To update the currently configured value for advanced options.
RECONFIGURE;
GO
-- To enable the feature.
EXEC sp_configure 'xp_cmdshell', 1;
GO
-- To update the currently configured value for this feature.
RECONFIGURE;
GO
And then just run
EXEC xp_cmdshell 'Systeminfo';
GO
Weird that it works now,because I couldn't get it to work past weeks.
I'm getting the following error when trying to open an Excel file in SQL Server 2008 r2 64-bit:
Msg 7399, Level 16, State 1, Line 1
The OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "(null)"
reported an error. The provider did not give any information about the error.
Msg 7303, Level 16, State 1, Line 1
Cannot initialize the data source object of OLE DB provider
"Microsoft.ACE.OLEDB.12.0" for linked server "(null)".
I'm using the following query:
SELECT * FROM OPENROWSET('Microsoft.ACE.OLEDB.12.0', 'Excel 12.0;
HDR=NO; IMEX=1; Database=\\filepath\filename.xlsx', 'SELECT * FROM [Sheet1$]')
The funny thing is that the DBA can run it without issue. I've gone through and ran the following queries:
sp_configure 'Show Advanced Options', 1;
RECONFIGURE;
GO
sp_configure 'Ad Hoc Distributed Queries', 1;
RECONFIGURE;
GO
EXEC sp_MSset_oledb_prop N'Microsoft.ACE.OLEDB.12.0', N'AllowInProcess', 1
GO
EXEC sp_MSset_oledb_prop N'Microsoft.ACE.OLEDB.12.0', N'DynamicParameters', 1
GO
The account that runs it looks like it has sa access. What could be causing this issue?
As Philip has said...first check the execution of xp_cmdshell. If it is not running due to permission issue then first reconfigure this option by running
SP_CONFIGURE 'XP_CMDSHELL',1
GO
RECONFIGURE
after this run following command to enable linked server permissions for InProcess capabilities for ACE driver :
USE [master]
GO
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
Now run this series of commands :
sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO
sp_configure 'Ad Hoc Distributed Queries', 1
GO
RECONFIGURE
if error encountered then run each command separately. And finally run import all your excel data to SQL server by running the below mentioned command :
SELECT * INTO TargetTableName FROM OPENROWSET('Microsoft.ACE.OLEDB.12.0',
'Excel 12.0;Database=FilePath\fileName.xlsx;HDR=YES',
'SELECT * FROM [sheetName$]')
Remember that in case of xls you have to use Jet Driver instead of ACE. And also the TargetTableName must not be existing prior to running this query.
Happy coding :)
have you tried (as a test) copying the Excel file onto the SQL Server C:\ drive and executing the query against that path?
what happens when you go onto the server and open this path in Explorer/run dialog: \filepath\filename.xlsx?
Are you able to execute this query: exec master..xp_cmdshell 'dir '\filepath\filename.xlsx'?
This will help you determine if it's a network rights issue, or whether the account has the permissions to use distributed queries.
My hunch is that it's definitely a rights/permission issue, as the DBA can run it.
Please use forward slash instead of back slash
Select * From OPENROWSET('MICROSOFT.ACE.OLEDB.12.0','EXCEL 12.0;DATABASE=//ComputerName/ShareMyLocation/DatabaseSheet.xlsx;IMEX=1','Select * From [SMDH-View2$]')
SQL Server Management Studio. Type Services.msc in the run command to open the services window.
Search for SQL Server Service and right click it and select properties.
In the Log On Tab, select system account/or select your domain ID and Account and password.
Once it finds your login name press OK.
Now type your login’s passwords in both the fields.
Restart the services so that the new changes are applied as shown in figure below.
Now start SQL Server Management Studio and try to run the query if still not working try a system restart.
or execute the query.
USE [master] GO 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