The following code works in my local instance of Sql Server but fails in remote instance with error Can you please help me out on this. Getting Error#
102: Incorrect syntax near '$.Location'
If (len(#JsonBODetails) > 0)
Begin
Insert Into #Temp_BOLines
SELECT * FROM
OPENJSON ( #JsonBODetails )
WITH (
Location varchar(2) '$.Location' ,
JCA varchar(4) '$.JCA'
)
End
Edit: SQL Server version. It is the same in both the cases.
Microsoft SQL Server 2017 (RTM-CU13-OD) (KB4483666) - 14.0.3049.1 (X64)
Dec 15 2018 11:16:42
Copyright (C) 2017 Microsoft Corporation
Web Edition (64-bit) on Windows Server 2016 Datacenter 10.0 (Build 14393: ) (Hypervisor)
Adding the complete procedure to repro this error
declare #JsonBODetails varchar(max)
SELECT * FROM
OPENJSON ( #JsonBODetails )
WITH (
Location varchar(2) '$.Location' ,
JCA varchar(4) '$.JCA'
)
Related
We have some code try to create a temp table on SQL Server with the following:
CREATE TABLE #POM_read_expr_scratch2 ( auid VARCHAR(15) collate Latin1_General_BIN, aint_val INT ) ;
SELECT MAX(partition_number) FROM sys.partitions WHERE object_id = object_id( '#POM_READ_EXPR_SCRATCH2' ) HAVING MAX(partition_number) > 1;
CREATE UNIQUE INDEX re_scratch_index ON #POM_READ_EXPR_SCRATCH2 ( auid ) ;
COMMIT;
This code work with SQL Server 2016 Developer version. however when run with 2019 Standard version (DBMS VERSION:: 15.0.2000.5 RTM Standard Edition (64-bit)) we get following error:
DBC error. SQLSTATE: 42000 Native error: 1088 Message:
[Microsoft][ODBC SQL Server Driver][SQL Server]Cannot find the object
"#POM_READ_EXPR_SCRATCH2" because it does not exist or you do not have
permissions. Approx SQL was "CREATE UNIQUE INDEX re_scratch_index ON
#POM_READ_EXPR_SCRATCH2 ( auid ) "
Error creating index re_scratch_index on table
#POM_READ_EXPR_SCRATCH2.
*** EIM_check_error: code 1088, dbmsg='[Microsoft][ODBC SQL Server Driver][SQL Server]Cannot find the object "#POM_READ_EXPR_SCRATCH2"
because it does not exist or you do not have permissions.'
We check the documentation, but didn't see any restriction of creating index on temp table. Can anyone explain why could this happens?
I think query you want is below:
CREATE TABLE #POM_read_expr_scratch2 (
auid VARCHAR(15) COLLATE Latin1_General_BIN INDEX re_scratch_index CLUSTERED
,aint_val INT
);
In our program (C#), we use the system stored procedure sp_cursorprepexec.
Now, on a somewhat newer customer environment, we get the following error message:
Cannot continue the execution because the session is in the kill state. A severe error occurred on the current command. The results, if any, should be discarded.
Recording the program crash on SQL Server Profiler shows the following error message:
Exception ex_trans_cexcept.
SQL Server Version there is "Microsoft SQL Server 2019 (RTM) - 15.0.2000.5 (X64)
Sep 24 2019 13:48:23
Copyright (C) 2019 Microsoft Corporation
Standard Edition (64-bit) on Windows Server 2019 Datacenter 10.0 (Build 17763: ) (Hypervisor)"
Script
declare #p1 int
set #p1=NULL
declare #p2 int
set #p2=0
declare #p7 int
set #p7=default
exec sp_cursorprepexec #handle=#p1 output,#cursor=#p2 output,#paramdef=N'#0 int, #1 int, #2 int, #3 varchar(50), #4 varchar(10)',#stmt=N'Select *
From [TABLE]
Where CustomerNumber = #0
And VersionNumber = #1
And ContactNumber = #2
And (om_db.[CUSTOMER]_AccessValidation (#3, BankAccountId, #4, ''Read'', ''DO.BankAccount'') = 1)
Order by AccountNumber, CustomerNumber, VersionNumber, ContactNummer, AccountIdentifier',#scrollopt=4097,#ccopt=98305,#rowcount=#p7 output,#0=205536,#1=0,#2=14,#3='[CUSTOMER]',#4='[USER]'
select #p1, #p2, #p7
Solution description
changing the compatibility level of the database from SQL Server 2019 (150) to SQL Server 2017 (140) solved the problem.
Does anyone has a clue what probably could cause this error?
Strange situation... New physical severs, new install of SQL Server 2019 Enterprise version :
Microsoft SQL Server 2019 (RTM) - 15.0.2000.5 (X64) Sep 24 2019 13:48:23 Copyright (C) 2019 Microsoft Corporation Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2019 Standard 10.0 (Build 17763: ).
Testing the performance by creating the first database like this :
CREATE DATABASE DB_BENCH
GO
DECLARE #SQL NVARCHAR(max) = N'';
SELECT #SQL = #SQL + N'ALTER DATABASE DB_BENCH MODIFY FILE (NAME = ''' + name + N''', SIZE = 10 GB, FILEGROWTH = 64 MB);'
FROM DB_BENCH.sys.database_files;
SET #SQL = #SQL + N'ALTER DATABASE DB_BENCH SET RECOVERY SIMPLE;'
EXEC (#SQL);
GO
And the objects in the database like this :
USE DB_BENCH
GO
SET NOCOUNT ON;
GO
CREATE TABLE T_TIME_INTERVAL_TIV
(TIV_ID INT NOT NULL IDENTITY PRIMARY KEY,
TIV_GROUP INT,
TIV_DEBUT DATETIME2(0),
TIV_FIN DATETIME2(0))
GO
TRUNCATE TABLE T_TIME_INTERVAL_TIV;
GO
BULK INSERT T_TIME_INTERVAL_TIV
FROM "C:\DATA_SQL\intervals.txt"
WITH (KEEPIDENTITY ,
FIELDTERMINATOR = '\t',
ROWTERMINATOR = '\n');
GO
CREATE VIEW V
AS
SELECT TIV_GROUP AS id, TIV_DEBUT AS intime, TIV_FIN AS outtime
FROM T_TIME_INTERVAL_TIV
GO
The intervals.txt datafile contains 1 million lines.
You can have it at :
https://1drv.ms/t/s!AqvZfiQYoNpBiCD65D4zaRbch5s-?e=UicEYu
The query that produce the bug :
WITH T1 As
(SELECT id, intime
FROM #T
UNION ALL
SELECT id, outtime FROM #T),
T2 As
(SELECT ROW_NUMBER() OVER(PARTITION BY id ORDER BY intime) NN, id, intime
FROM T1 T1_1),
T3 As
(SELECT T2_1.NN - ROW_NUMBER() OVER(PARTITION BY T2_1.id ORDER BY T2_1.intime,T2_2.intime) NN1,
T2_1.id, T2_1.intime intime, T2_2.intime outtime
FROM T2 T2_1
INNER JOIN T2 T2_2
ON T2_1.id=T2_2.id
And T2_1.NN=T2_2.NN-1
WHERE EXISTS (SELECT *
FROM V S
WHERE S.id=T2_1.id
AND (S.intime < T2_2.intime AND S.outtime>T2_1.intime))
OR T2_1.intime = T2_2.intime)
SELECT id, MIN(intime) intime, MAX(outtime) outtime
FROM T3
GROUP BY id, NN1
ORDER BY id, intime, outtime;
We tested this query on 2 different servers... with the same SQL Server installation.
The result is always :
Msg 601, Level 12, State 1, Line ...
Could not continue scan with NOLOCK due to data movement.
With an installation of :
SQL Server 2019 (RTM) - 15.0.2000.5 (X64) Sep 24 2019 13:48:23 Developer Edition (64-bit) on Windows Server 2019 Standard 10.0 (Build 17763: ) (Hypervisor)
There is no problem...
We tested the databases with DBCC CHECKDB () WITH DATA_PURITY. No errors.
Can you reproduce with your different editions/patches (CU) and give me your results for which are alright or not ?
If some of you have already the bug I will add an entry in SQL Azure feedback...
Thanks
After many investigation, we found that it is really a SQL Server bug.
The bug disappear when we execute a :
UPDATE STATISTICS T_TIME_INTERVAL_TIV WITH FULLSCAN;
Or when whe "hint" the query with OPTION (MAXDOP 1)
Sometime a stack dump appear (not Always) showing this type of messages :
A time-out occurred while waiting for buffer latch -- type 4, bp 0000029BA883BDC0, page 9:407, stat 0x10b, database id: 2, allocation unit Id: 422212465393664/140737488683008, task 0x0000029B86723848 : 14, waittime 300 seconds, flags 0x1a, owning task 0x0000029B86713848. Not continuing to wait.
Which is the tempdb. A Stack Dump is systematically recorded on file.
We will call the MS hotline as soon as possible.
Thanks to all of you.
Interestingly enough I found no post for this specific, but basic issue.
Goal: update the latest budgetid record docstatus = 0. Then I want to update the next-to-last budgetid record docstatus = 1. I am trying this within PHP but also testing in my SQL Server SEM and it is failing there, too.
My SQL Server statement:
select
budgetid, docstatus, datechanged
from
ccy_budget
where
activityid = 11111
order by
datechanged desc
limit 1,1;
Error that occurs in SEM is:
Incorrect syntax near 'limit'.
Yet in w3schools this [sample] sql works just fine:
SELECT *
FROM Customers
ORDER BY postalcode DESC
LIMIT 1,1;
Seems so simple, surely I am missing something fundamental.
Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64)
Apr 2 2010 15:48:46
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.2 <X64> (Build 9200: ) (Hypervisor)
Equivalent syntax in SQL Server would be
select *
from table
order by somerow desc
offset 1 rows fetch next 1 rows only;
But the above is available from SQL Server 2012 on, so for your version, you have to some thing like below
;with cte
as
(
select *,row_number() over (order by postalcode desc) as rn
from table
)
select * from cte where rn=2
I'm having a problem with a GUID which I've narrowed down to what looks like a problem with the LIKE operator.
When the following is run on my server
DECLARE #Problem NVARCHAR(1000) = N'58C21BC6-081B-4E57-BFE1-5B11AAC662F1';
DECLARE #GuidPattern NVARCHAR(1000) =
REPLICATE('[0-9A-Fa-f]', 8)
+ '-'
+ REPLICATE('[0-9A-Fa-f]', 4)
+ '-'
+ REPLICATE('[0-9A-Fa-f]', 4)
+ '-'
+ REPLICATE('[0-9A-Fa-f]', 4)
+ '-'
+ REPLICATE('[0-9A-Fa-f]', 12);
SELECT
CASE
WHEN #Problem LIKE #GuidPattern THEN 1
ELSE 0
END AS [FollowsPattern];
the answer is 0, but when I run the exact same code on my local machine the answer is 1.
It looks pretty obvious to me that the string is in fact a valid GUID, so the answer should be 1 in both cases. All the other ways I know about to confirm that the GUID is valid also succeed, both locally and on the server:
SELECT
CASE
WHEN CAST(#Problem AS UNIQUEIDENTIFIER) = #Problem THEN 1
ELSE 0
END AS [IsGuid1]; -- 1
SELECT
CASE
WHEN CONVERT(UNIQUEIDENTIFIER, #Problem) = #Problem THEN 1
ELSE 0
END AS [IsGuid2]; -- 1
SELECT
CASE
WHEN TRY_CONVERT(UNIQUEIDENTIFIER, #Problem) IS NOT NULL THEN 1
ELSE 0
END AS [IsGuid3]; -- 1
The server version is
Microsoft SQL Server 2016 (RTM) - 13.0.1601.5 (X64)
Apr 29 2016 23:23:58
Copyright (c) Microsoft Corporation
Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2012 R2 Standard 6.3 <X64> (Build 9600: ) (Hypervisor)
and my local installation version is
Microsoft SQL Server 2014 - 12.0.2000.8 (X64)
Feb 20 2014 20:04:26
Copyright (c) Microsoft Corporation
Express Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)
The default collation is the not the same (SQL_Latin1_General_CP1_CI_AS locally and Danish_Norwegian_CI_AS on the server), but I don't think that should matter since I'm dealing with Unicode anyway. Adding an extra COLLATE clause on either machine with the other's collation makes no difference. Update: Not true, the collation is the source of the problem. I only tested different collations in the variable declaration, not in the comparison itself.
I suppose the problem is COLLATION.
Have a look at: http://rextester.com/IRQEFU33639
If you use default collation:
SELECT
CASE
WHEN #Problem LIKE #GuidPattern THEN 1
ELSE 0
END AS [FollowsPattern];
The result = 1
Instead, if you forces Danish_Norwegian_CI_AS collation:
SELECT
CASE
WHEN #Problem collate Danish_Norwegian_CI_AS LIKE #GuidPattern THEN 1
ELSE 0
END AS [FollowsPattern];
It returns 0.
I'd suggest to force the collation to SQL_Latin1_General_CP1_CI_AS or other collation that works well.
SELECT
CASE
WHEN #Problem COLLATE SQL_Latin1_General_CP1_CI_AS LIKE #GuidPattern THEN 1
ELSE 0
END AS [FollowsPattern];
And just to make it easy maybe using an INLINE User Defined Function.
Force to a standard collation
SELECT
CASE
WHEN #Problem COLLATE Latin1_General_CI_AS LIKE #GuidPattern COLLATE Latin1_General_CI_AS THEN 1
ELSE 0
END AS [FollowsPattern];
The reason is how "a" is matched in Danish_Norwegian_CI_AS collation.
See SQL 'Like' operator and 'aa' for more where I demonstrated it with Danish_Norwegian_CI_AS