I have a Scalar-valued Function that I've been using for years in my database. Its always worked correctly. I recently moved the database to SQL Server 2019 and when I changed the compatibility level to SQL Server 2019 (150), my function blew up like nitroglycerin. Reverting the compatibility level back down to SQL Server 2017 (140) allowed things to function as normal.
This is the function:
CREATE FUNCTION [dbo].[Authentication_SHA1ToBase64](#source AS varchar(8000))
RETURNS varchar(8000)
BEGIN
DECLARE
#bin varbinary(8000),
#result varchar(8000)
SET #bin = CONVERT(varbinary(8000), #source)
RETURN CAST(N'' as xml).value('xs:base64Binary(xs:hexBinary(sql:variable("#bin")))', 'varchar(8000)')
END
At SQL Server 2019 (150) compatibility level, the following:
SELECT [dbo].[Authentication_SHA1ToBase64]('0x640AB2BAE07BEDC4C163F679A746F7AB7FB5D1FA')
Errors as follows:
Msg 596, Level 21, State 1, Line 0
Cannot continue the execution because the session is in the kill state.
Msg 0, Level 20, State 0, Line 0
A severe error occurred on the current command. The results, if any, should be discarded.
The odd thing is that if I just execute the same as a query:
DECLARE
#bin varbinary(8000)
SET #bin = CONVERT(varbinary(8000), '0x640AB2BAE07BEDC4C163F679A746F7AB7FB5D1FA')
SELECT [Result]=CAST(N'' as xml).value('xs:base64Binary(xs:hexBinary(sql:variable("#bin")))', 'varchar(8000)')
I get the expected result:
Result
--------------------------------------------------------
MHg2NDBBQjJCQUUwN0JFREM0QzE2M0Y2NzlBNzQ2RjdBQjdGQjVEMUZB
Maybe there's some internal async issue that's breaking the function? Anyone have an idea if there's a newer method in SQL Server 2019 to convert to base64?
UPDATE: ##VERSION is: Microsoft SQL Server 2019 (RTM-GDR) (KB4583458) - 15.0.2080.9 (X64) Nov 6 2020 16:50:01 Copyright (C) 2019 Microsoft Corporation Standard Edition (64-bit) on Windows Server 2019 Datacenter 10.0 (Build 17763: ) (Hypervisor)
I updated to CU9, modified compatibility back to 150, and it works! Microsoft SQL Server 2019 (RTM-CU9) (KB5000642) - 15.0.4102.2 (X64) Jan 25 2021 20:16:12 Copyright (C) 2019 Microsoft Corporation Standard Edition (64-bit) on Windows Server 2019 Datacenter 10.0 (Build 17763: ) (Hypervisor)
Related
I recently started using sys.dm_os_enumerate_filesystem.
My SQL Server version is:
(Microsoft SQL Server 2017 (RTM-CU31) (KB5016884) - 14.0.3456.2 (X64) Sep 2 2022 11:01:50 Copyright (C) 2017 Microsoft Corporation Developer Edition (64-bit) on Windows Server 2012 Standard 6.2 (Build 9200: ) (Hypervisor) )
Everything worked fine until I started querying filesystems where the directories are very large.
The following query generated the error:
SELECT *
from sys.dm_os_enumerate_filesystem('F:\technician','*');
Msg 407, Level 16, State 1, Line 15
internal error. The string routine in file sql\ntdbms\storeng\dfs\alloc\storagedmv.cpp, line 799 failed with HRESULT 0x8007007a.
The directory is 460 GB. I have also checked all permission and SQL Server service has all permission on the above directory.
As you can see the SqlServer is running with the last CU31.
Is there a workaround?
The time specified in the waitfor delay is not honored in SQL Server Linux on Docker Desktop for Windows.
Script:
declare #tsstart varchar(100) = CONVERT (VARCHAR(100) , SYSDATETIME() ,121);
raiserror(#tsstart,0,0) with nowait;
WAITFOR DELAY '00:00:15';
declare #tend varchar(100) = CONVERT (VARCHAR(100) ,SYSDATETIME(),121 );
raiserror(#tend,0,0) with nowait;
Output:
2021-03-25 23:05:23.4457947
2021-03-25 23:05:33.0387152
I would expect the #tend would be 2021-03-25 23:05:38.4457947 (because i specified 15 seconds in my waitfor.
The same code executes fine on a SQL Server installed on Windows 10 Pro (laptop). Anything I am missing?
Environment :
SQL Server Linux (2019)
Microsoft SQL Server 2019 (RTM-CU9) (KB5000642) - 15.0.4102.2 (X64)
Jan 25 2021 20:16:12
Copyright (C) 2019 Microsoft Corporation
Developer Edition (64-bit) on Linux (Ubuntu 18.04.5 LTS) <X64>
Docker for Desktop Windows (Linux Container) (Docker engine: v20.10.5)
I have a proprietary software that communicates with sql server database for storing data and trying to insert/update records behind the scenes.
Running Select ##version on server returns
Microsoft SQL Server 2014 (SP2-GDR) (KB4019093) - 12.0.5207.0 (X64)
Jul 3 2017 02:25:44
Copyright (c) Microsoft Corporation
Express Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)
server collation is Slovenian_CI_AS, but all string columns in tables are declared with:
DATA_TYPE: nvarchar
CHARACTER_SET_NAME: UNICODE
COLLATION_NAME: SQL_Latin1_General_CP1_CI_AS
Now if I try updating a field, for example:
UPDATE CategoryText SET Title = 'č' WHERE Category_Id = 1 AND LanguageId = 1060"
The software displays Ä as a title.
Of course, I get the right result (letter č) if i run the following query from the console
select Title from CategoryText where Category_Id = 1 AND LanguageId = 1060
But I would like to insert the text the way that will be displayed properly in the software.
Doing this from ubuntu with en_US.UTF-8 local settings, tried also from windows without luck.
I can change my local settings, I can change the collation of the string I'm importing.
I cannot change the way software is communicating with the server and I do not think I can alter the tables in the database.
I have a simple insert, but with greek characters
INSERT INTO tmp (fname) VALUES ('ΚΩΝΣΤΑΝΤΙΝΟΣ')
I have tried creating the table in two ways:
create table tmp (fname varchar(40))
and
create table tmp (fname nvarchar(40))
When I then select the data:
select * from tmp
I get:
?O?S???????S
I'm using:
Microsoft SQL Server 2005 - 9.00.4060.00 (Intel X86)
Mar 17 2011 13:20:38
Copyright (c) 1988-2005 Microsoft Corporation
Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 2)
and
Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64)
Oct 19 2012 13:38:57
Copyright (c) Microsoft Corporation
Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)
it does the same in both.
I'm using:
Microsoft SQL Server Management Studio 11.0.2100.60
to create the table and insert the data etc.
How do I get Greek characters to store correctly or if they are stored correctly to display correctly when I select them?
Try to use prefix Unicode character string:
create table tmp (fname nvarchar(40))
INSERT INTO tmp (fname) VALUES (N'ΚΩΝΣΤΑΝΤΙΝΟΣ')
Also there may be a problem with collation of the columns, please set
create table tmp (fname nvarchar(40) COLLATE SQL_Latin1_General_CP1253_CI_AI)
From MSDN:
Prefix Unicode character string constants with the letter N. Without
the N prefix, the string is converted to the default code page of the
database. This default code page may not recognize certain characters.
I'm puzzling with a Stored procedure that has different behavior when run with an withoout the Exec keyword.
I have 2 servers, Server 1:
Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) Apr 2 2010 15:48:46 Copyright (c) Microsoft Corporation Standard Edition (64-bit) on Windows NT 6.0 (Build 6002: Service Pack 2) (Hypervisor)
Server 2:
Microsoft SQL Server 2008 (SP2) - 10.0.4000.0 (X64) Sep 16 2010 19:43:16 Copyright (c) 1988-2008 Microsoft Corporation Standard Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1) (VM)
A stored procedure (ACTUALIZA_MANTE_FULL) in Server 1 that deletes and inserts data to a table in Server 2 from tables in server 1.
When I run "EXEC ACTUALIZA_MANTE_FULL" the process returns no errors but the destinatio table has no rows.
When I run "ACTUALIZA_MANTE_FULL" (without EXEC) the process runs with no errors and the data is inserted correctly.
Why the difference?, what i'm missing?
EDIT: procedure pseudo code (sorry can't put actual code)
CREATE PROCEDURE MIPROC<br>
AS <br>
declare #from datetime<br>
set #from = getdate()-30<br>
<br>
delete from [ADMSRV].remotedb.dbo.remoteTable where t_date >= #from<br>
<br>
Insert into [ADMSRV].remotedb.dbo.remoteTable <br>
Select fields, sum(datum) as datum<br>
form localdb.dbo.localtable1<br>
where ld_date >= #from<br>
group by ields <br>
union <br>
Select fields, sum(datum) as data<br>
form localdb2.dbo.localtable2<br>
where ld_date >= #from<br>
group by fields<br>
GO<br>
the fields in (fields) are same cuantity, and type of PK in remoteTable
Remote table has PK only, no FK, no unique constraint, no unique index or triggers.