I just found a what i think is a bug in Azure SQL. Microsoft SQL Azure (RTM) - 12.0.2000.8
Any idea what's going on here?
create procedure dummyProc
as
declare #myVar nvarchar(20) = 'data'
select myVar = #myVar
into #temp
Executing the code generates an error:
Msg 156, Level 15, State 1, Line 1
Incorrect syntax near the keyword 'PROCEDURE'.
Msg 8180, Level 16, State 1, Procedure sp_describe_parameter_encryption, Line 1 [Batch Start Line 0]
Statement(s) could not be prepared.
An error occurred while executing batch. Error message is: Internal error. Metadata for parameter '#p10c873e7e2034dd29022eb675d63dfbb' in statement or procedure 'CREATE PROCEDURE dummyProc
AS
DECLARE #myVar AS NVARCHAR (20) = #p10c873e7e2034dd29022eb675d63dfbb;
SELECT #myVar AS myVar
INTO #temp;
' is missing in resultset returned by sp_describe_parameter_encryption.
Thanks for reporting this issue. This is indeed a problem in SSMS and, sadly, it is still an issue in the latest version of SSMS 18.x.
The issue is that parameterization is trying to parameterize declare statements inside of a create stored proc statement.
We (SSMS Team) will do our best to address it in a future version of SSMS.
In the interim, the suggested way to unblock you would be to disable parametrization, by going to "Tools | Options | Query Execution | SQL Server | Advanced" and making sure that "Enable Parametrization for Always Encrypted" is unchecked.
Upgrading to 18.2 fixed the issue.
In earlier versions, using always encrypted with the query option Enable Parameterization for Always Encrypted would cause the error.
Thanks for your comments and help!
Related
I'm writing a script in Sybase ASE where I call a stored procedure in SQL Server. The problem I have is that I'm getting an error from Sybase but not from SQL Server.
The Script in Sybase is as follows:
declare #input varchar(4000)
select #input = '111,222,333,444,555'
exec GATEWAY.MyDataBase..MyStoredProcedure #input
And this is the error:
[Error] Script lines: 1-5 --------------------------
Conversion failed when converting the varchar value '555.............................................................................................................................................' to data type int.
Msg: 245, Level: 16, State: 1
Server: GATEWAY, Line: 0
My stored procedure in SQLServer
I don't know why Sybase adds that right padding. The only way I can get it work is declaring the variable #input as varchar(255) or shorter.
What I tried without luck:
Adding a rtrim and ltrim in sybase
Setting the variable as TEXT
Adding rtrim and ltrim in SQLServer
adding a replace(#input,' ', '')
Wanted to replicate the problem in SQLServer adding the pad to the right but it still works.
The important thing is that: I can excecute it from SQLServer but it throws error from Sybase with the same input data.
Any help would be very appreciated. I guess it has something to do with the size of the varchar but no clue yet.
You can create a remote procedure in Sybase like this:
CREATE PROCEDURE "DBA"."uspSQL_CreateTicketsByCaseNo;1"( in #caseNo varchar(8) )
at 'SQL;dbName;dbo;uspSQL_CreateTicketsByCaseNo'
You can also right-click the Procedures & Functions and use the wizard to create a remote procedure. Then call the remote procedure like this:
CALL "DBA"."uspSQL_CreateTicketsByCaseNo;1"( caseNo )
It works for me.
I'm trying to create the following stored proc with table-valued type as one of the parameter. However, I'm getting error as
Incorrect syntax near 'READONLY'.
I've checked many stackoverflow responses which mentions that the reasons could be sql server version. This is what my ##version tells me and looks fine to me
Microsoft SQL Server 2014 (RTM-CU14) (KB3158271)
Create PROCEDURE [dbo].[Customer_Select](
#variableTable dbo.CustomVariableType READONLY,
#return BIT = NULL OUTPUT)
AS
BEGIN
SELECT * FROM Customer
SET #return=1
END
Appreciate your help in this regard
It started to work after I restarted SSMS. Weird!!
I am migrating from SQL Server 2005 to SQL Server 2014 and one of the queries stopped working in SQL Server 2014:
select *
from openrowset ('SQLOLEDB','Server=(local);TRUSTED_CONNECTION=YES;',' exec [MyDatabase].[dbo].[MyTable]')
I get the following error message:
Msg 11529, Level 16, State 1, Procedure sp_describe_first_result_set,
Line 1
The metadata could not be determined because every code path results in an error; see previous errors for some of these.
Msg 4902, Level 16, State 1, Procedure sp_describe_first_result_set, Line 1
Cannot find the object "#MyTempTable" because it does not exist or you
do not have permissions.
dbo.MyTable and #MyTempTable are not real names.
What could cause this error? Any help would be appreciated.
Thanks
From SQL Server 2012 onwards, you need to use WITH RESULT SETS to explicitly describe the result set:
EXEC('exec [MyDatabase].[dbo].[StoredProcedure] WITH RESULT SETS (( val SMALLINT));')
I have SQL server and It has another SQL server Linked server [DEV]. Now I want call a stored procedure in Linked server and get the result value. It is always giving error. I tried below both statements none of the did not worked.
ALTER PROCEDURE [dbo].[UpdateMemebership_Lock_Count]
#v_constit_id_in as varchar(100)
AS
BEGIN
Exec ('Call [Members_Directory_Search_DEV].[dbo].[update_dirsearch_notes]
(?)',#v_constit_id_in) AT [DEV]
--Exec [DEV]..[Members_Directory_Search_DEV].[update_dirsearch_notes]
#v_constit_id_in
END
Error
Msg 102, Level 15, State 1, Line 1
Incorrect syntax near '.'.
Not sure what syntax you are used to using (CALL is used for Analysis Services, not SQL Server), but linked servers have a four part notation:
ServerName.DatabaseName.owner.object
Try:
Exec [DEV].[Members_Directory_Search_DEV].dbo.[update_dirsearch_notes] #v_constit_id_in
We sometimes write dataport scripts that rename tables or columns and have other complex logic. We also have SQL in IF statements referencing those old columns or tables. We have a standard to use IF statements to make our SQL Scripts multi run friendly.
However occasionally, even though the if statement evaluates to false, the code wrapped in the block errors out, I'm guessing because of a syntax check.
if 1 = 0
begin
select * from mydatabase.dbo.mytable; -- doesn't execute, but still errors because doesn't exist
end
Another weird thing is it isn't always consistent, sometimes it works fine.
Does anybody know if a way I can disable these sort of checks on a script by script basis.
Thanks
NOTE
I know people are going to say they tried a similar situation and it doesn't error. At first for me it didn't error in SSMS but it errored in SQLCMD.
sqlcmd MyTestScript.sql -r 1 -U user -P password
Then I put SSMS in SQLCMD mode Query -> CMDMODE and it still didn't give the error.
Then after rerunning a few times it started to error in both.
Try to use TRY-CATCH blocks, easy to use and elegant.
if 1 = 0
BEGIN TRY
select * from mydatabase.dbo.mytable;
END TRY
BEGIN CATCH
--error handling code
SELECT ERROR_MESSAGE()
END CATCH
I think execute_sql built in stored procedure can work around this.
Run the following code in your dev environment
DROP Procedure dbo.#TestProc
GO
CREATE Procedure dbo.#TestProc
AS
IF 1=0
BEGIN
SELECT 1 FROM XXXXX
END
ELSE
BEGIN
SELECT *
FROM Information_Schema.Tables
WHERE Table_Name = 'XXXXX'
END
GO
EXEC #TestProc
It compiles. It executes. It does not error out during either compilation or execution.
I am using SQL 2005.
As you can see from the results, there is no table called XXXXX.
I think your conditions are actually being met and the code is executing.
Edt
I went further than what I typed:
The stored proc gets created and runs for each one of the following
SELECT * FROM XXXXX.XXXXX /* owner XXXXX */
SELECT * FROM XXXXX.XXXXX.XXXXX /* database XXXXX */
The code bombs out when I fully qualify the name
SELECT * FROM XXXXX.XXXXX.XXXXX.XXXXX /* linked server XXXXX */
Now it LOOKS for the linked server and does not find one and throws an error.
Msg 7202, Level 11, State 2, Procedure #TestProc, Line 6
Could not find server 'XXXXX' in sys.servers.
Verify that the correct server name was specified.
If necessary, execute the stored procedure sp_addlinkedserver
to add the server to sys.servers.
Msg 2812, Level 16, State 62, Line 1
Could not find stored procedure '#TestProc'.
A blunt instrument, but you can ignore errors.
:On Error ignore in the script?
-b and -V to ignore "severity < V" (Not tried it). Could be useful to detect "no object" errors but throw your own above V severity when there is really an error.
See SQLCMD in MSDN