When I execute the following the code below on my Azure SQL Database I get the following error:
'sp_executesql' not supported on this version of SQL Server
EXECUTE sp_executesql #ColumnMetadataSQL, #ParmDefinition, #ColumnMetadataOUT=#ColumnMetadata OUTPUT;
I'm not sure why I'm getting this error as 'sp_executesql' is supported on Azure SQL Database
https://learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-executesql-transact-sql?view=sql-server-ver16
Any thoughts?
Azure SQL Database sp_executesql not supported on this version of SQL Server
As its giving did not support this version error looks strange because the sp_executesql command is supported in SQL Server versions (nearly all) i.e. 2000, 2005, 2008, 2008R2, 2012, 2014 or higher.
I tried to reproduce but it's working fine for me. with same SQL version as you.
Code and Execution in SSMS and Azure Query editor:
DECLARE #SQLString NVARCHAR(500);
DECLARE #ParmDefinition NVARCHAR(500);
DECLARE #SalesOrderNumber NVARCHAR(25);
SET #SQLString = N'SELECT #taskObtainedScoreOUT = MAX(taskObtainedScore)
FROM [dbo].[samplejson4]';
SET #ParmDefinition = N'#taskObtainedScoreOUT NVARCHAR(25) OUTPUT';
EXECUTE sp_executesql #SQLString,#ParmDefinition,#taskObtainedScoreOUT = #SalesOrderNumber OUTPUT;
SELECT #SalesOrderNumber ;
SQL version:
Once Check your code and query parameter if still issue persist the issue might be from azure server side for deeper investigation you can raise support ticket to Microsoft team from here.
Related
I have access to an Access database and within that database are fields filled with TSQL queries. These queries are processed by T-SQL on a server. So when I write these SQL queries and put them into a field for use by the end server, I'm unable to validate the syntax/etc. I could create a temporary query in that Access database, but it's not the same query language. For example, Access would correctly use IIF but TSQL would not (it would instead be CASE).
I don't have direct access to this server with TSQL, is there a way I can validate my T-SQL queries (for syntax and the like)? Perhaps a web tool online?
I should note I do not have access to the SQL server. Only the Access db and that alone. I understand it will not validate table names and the like, I wouldn't expect it to.
Actually, a combination of MattMc3's answer and FremenFreedom's answer should work.
Download SQL Express.
Then, declare the following stored procedure:
create procedure IsValidSQL (#sql varchar(max)) as
begin
begin try
set #sql = 'set parseonly on;'+#sql;
exec(#sql);
end try
begin catch
return(1);
end catch;
return(0);
end; -- IsValidSQL
You can test it with:
declare #retval int;
exec #retval = IsValidSQL 'select iif(val, 0, 1) from t';
select #retval
or with:
declare #retval int;
exec #retval = IsValidSQL 'select val from t';
select #retval
Note: this will catch the IIF() issue. It will not catch anything related to the table structures or column structures. You would need the schema for that and a slightly different approach ("select top 0 * from () t") woudl do it.
You might be able to do something with SQL Fiddle online. However, I would suggest having a local copy of the database.
You can parse your T-SQL to check for valid syntax by executing it on the SQL Server machine with a SET PARSEONLY ON as the first line of your script. It will not validate table or field names, but will provide you with any syntax errors.
The Data Dude (Gert Drapers) describes how to use the built-in SQL Server T-SQL parser in your application here:
Getting to the Crown Jewels
If you want to only check the validity of the SQL statements that you have - this might be a nice way to go, and it doesn't require SQL Server per se to be installed where you run your unit tests.
It's a .NET based approach, and it cannot - of course - validate object names in your database if you're not using a live database - but it can catch syntactical errors in your T-SQL statements.
You can use the NOEXEC option:
SET NOEXEC ON
SELECT 1 AS Test
SET NOEXEC OFF
Is SQL Server Management Studio Express (free download) able to connect to regular SQL Server instances? If so, perhaps you could test the queries there. Even if you could not connect to the actual server, you might be able to create a test version of your database in Express that would at least allow you to catch syntax and naming problems.
If they are fairly static, convert them into stored procedures in the Sql Database and then just call them from access.
I am trying to import .dbf files into SQL Server 2016 64bit. For this I installed Microsoft Visual FoxPro. Below setup works for 32bit version of SQL Server but not to 64bit. I also tried changing the driver's name eg: Microsoft.Jet.OLEDB.4.0, Microsoft.ACE.OLEDB.16.0, etc. but no luck.
USE [master]
GO
EXEC sp_configure 'show advanced options', 1
RECONFIGURE
GO
EXEC sp_configure 'ad hoc distributed queries', 1
RECONFIGURE
GO
USE [master]
GO
EXEC master.dbo.sp_MSset_oledb_prop N'VFPOLEDB', N'AllowInProcess', 1
GO
And then,
DECLARE #sql AS NVARCHAR(200),
#path AS NVARCHAR(200),
#table AS NVARCHAR(200)
SET #path = 'C:\Users\sid\Downloads\VPF\'
SET #table = 'dmfiles'
SET #sql = 'Select * from openrowset(''VFPOLEDB'','''+#path+''';'''';'''',''select * from '+#table+'.dbf'')'
EXEC sp_executesql #sql
Also tried creating a Linked server type of cmd:
SELECT *
FROM OPENROWSET ('MICROSOFT.ACE.OLEDB.12.0','dBase
5.0;HDR=YES;IMEX=2;DATABASE=\Dbf Directory\','SELECT * FROM dbf_filename.dbf')
When I either try to open Linked server, run any command, SQL Server just says executing and never shows any result nor throws error.
I tried using DBF Viewer 2000 to convert .dbf to .sql and ran them against a DB but, running above SQL (if worked fine) would be great for my automation script.
Help is much appreciated!
I am attempting to use the SQL profiler and Tuning wizard to investigate index usage in my SQL 2008 R2 database.
The application connects to the db using ODBC. The db has not Stored Procedures and all the data is accessed using SQL statements.
The profiler shows the statement as
declare #p1 int
set #p1=10234
exec sp_prepexec #p1 output,N'#P1 varchar(max),#P2 varchar(max),#P3 int,#P4 int',
N'SELECT p.PaymentID from Payment where DivisionCode = #P1 and [...],','DM','A',1,1
select #p1
The tuning wizard will analyse the data and give a warning
49% of consumed workload has syntax errors. Check tuning log
The log shows the reason
Event does not reference any tables.
or
[Microsoft][SQL Server Native Client 10.0][SQL Server]Invalid object name 'Payment'.
What settings do I need to use to get the tuning wizard to understand the sp_prepexec queries?
What changes must I make to the trace file to make it useable by the tuning wizard?
Thanks.
I was able to get mine to work! Simply comment out the set statement like this:
declare #p1 int;
--set #p1=9
exec sp_prepexec #p1 output,N'#p0 bit,#p1 varchar(8000),#p2 bit',N'select blah from blah where #p0=1 and blah.LastName=#p1',#p0=0,#p1='Kumar'
select #p1
Hello Microsoft SQL Server Masters,
Well, I have an Microsoft SQL Server 2000 as described below:
Microsoft SQL Server 2000 - 8.00.2039 (Intel X86)
May 3 2005 23:18:38
Copyright (c) 1988-2003 Microsoft Corporation
Desktop Engine on Windows NT 5.2 (Build 3790: Service Pack 2)
I need to execute an Operating System command from this Microsoft SQL Server, I checked that I have sysadmin privileges with the query below and it returned "1", which confirm my privilege.
SELECT IS_SRVROLEMEMBER('sysadmin', 'sa');
I tried the traditional xp_cmdshell and nothing happened, just to make sure it was working I tried the famous:
EXEC xp_cmdshell 'dir c:\'; EXEC master.dbo.xp_cmdshell 'dir c:\';
EXEC master..xp_cmdshell "dir c:\";
And all returned NOTHING, which make me believe that xp_cmdshell is not available. I know that xp_cmdshell comes disable by default in Microsoft SQL Server 2005, but not in 2000, anyway, I tried to reenable it on the same way but it failed.
I looked at internet and I found this way to reenable xp_cmdshell for Microsoft SQL Server 2000:
exec sp_addextendedproc 'xp_cmdshell', 'xplog70.dll'
exec sp_addextendedproc xp_cmdshell, 'C:\Program Files\Microsoft SQL Server\MSSQL\Binn\xplog70.dll'
However, it still doesn't work. I found another article telling that sometimes admins delete this files and I think it may be my case, the article says that if it was deleted I can execute "xp_msver" and in my case it also return nothing.
Reference: http://support.microsoft.com/kb/891984
I also tried this query that I found on the internet to see if xp_cmdshell exist and it returned nothing (but it may be a limitation of my weird SQL client, see below please).
if exists (select * from dbo.sysobjects where id = object_id(N’[dbo].[ xp_cmdshell]‘) and OBJECTPROPERTY(id, N’IsExtendedProc’) = 1);
So, I'm really in trouble, I researched at Google and found potential solutions such as Job agent, SSIS package, CLR stored procedure, sp_OACreate (and friends) and SQLCMD but nothing worked. Maybe I did it incorrect, but another limitation in my case is that I just have access to this Microsoft SQL Server 2000 from a jump-box (Linux) that has a very odd sql-server client that do not accept queries with multiple lines, consequently I can't try with success the following potential solutions:
1# Job Agent
DECLARE #jobID uniqueidentifier, #cmd varchar(1000)
SET #cmd = 'netstat -na > c:\connections.txt'
EXEC msdb.dbo.sp_add_job #job_name = '_tmp_MakeDirectory', #enabled = 1, #start_step_id = 1, #owner_login_name='sa', #job_id = #jobID OUTPUT
EXEC msdb.dbo.sp_add_jobstep #job_id = #jobID, #step_name = 'Create Backup Folder', #step_id = 1, #subsystem = 'CMDEXEC', #command = #cmd
EXEC msdb.dbo.sp_add_jobserver #job_id = #jobID
EXEC msdb.dbo.sp_start_job #job_id = #jobID, #output_flag = 0
WAITFOR DELAY '000:00:05' -- Give the job a chance to complete
IF EXISTS (SELECT name FROM msdb.dbo.sysjobs WHERE name = '_tmp_MakeDirectory')
BEGIN
EXEC msdb.dbo.sp_delete_job #job_name = '_tmp_MakeDirectory'
END
2# SQLCMD
CREATE PROCEDURE SQLCMD_TEST
AS
!!MKDIR "netstat -na > c:\connections.txt"
:OUT "C:\TEST\test.TXT"
SELECT ##VERSION AS 'SERVER VERSION'
!!DIR
GO
SELECT ##SERVERNAME AS 'SERVER NAME'
GO
EXEC SQLCMD_TEST
Unfortunately I don't have any other way to access this Microsoft SQL Server, I know it's not the best way, but it's how it's and I can't do anything. So, I need a solution to execute Operating System commands on this Microsoft SQL Server 2000 with all this limitations. Can someone port any of the two above methods for one single line query, please?
Any other suggestion with example is very welcome.
Thanks a lot.
Regards.
I used to use xp_cmdshell before CLR support came along. Unfortunately, you are a version away from CLR support (SQL Server 2005) and the system.io namespace. You can, however, create your own extended stored procedures which can access the file system and create directories. See here for more info: http://www.devarticles.com/c/a/SQL-Server/Extended-Stored-Procedures-Intro-And-10-Cool-Examples/
By the way, xp_cmdshell is an extended stored procedure.
I am running SQL Server 2005 on Windows Server 2003 machine.
I have a requirement to accumulate small text files into a bigger one.
So I use
exec xp_cmdshell #sql
where #sql=
'copy /b'+#sourcePath+#sourceFile+' '+#destinationPath+#NewFileName
Both the source and destination paths are on a separate server.
Seldom this process fails and I don't find anything else in the event or SQL Server logs.
The Surface Area Config for xp_cmdshell is also enabled.
Please help.....
I just tested this on my sql server 2005 and EXEC dbo.xp_cmdshell always returns output (even in the case of a bogus command) in the form of a table. For C#, if you call this code with ExecuteNonQuery, then call it with ExecuteReader and read the output. Alternatively, you could dump the output in a table so that you can look at it later at your leisure. Create a table like this :
CREATE TABLE [dbo].[xp_cmdShellOutput](
[errorMsg] [nvarchar](max) NULL
)
and then use this code :
DECLARE #sql AS VARCHAR(600)
SELECT #sql = '<your command>'
INSERT dbo.xp_cmdShellOutput(errorMsg)
EXEC dbo.xp_cmdshell #sql