When I run the following SQL at my local SQL Server instance:
DECLARE #t DATETIME2 = '2019-12-12 00:00:00'
I get the following error:
Unable to convert #t to a System.Data.SqlClient.SqlParameter object. The specified literal cannot be converted to DateTime2(System.Data.SqlDbType), as it used an unsupported date/time format. Use one of the supported date/time formats. Literal value: 2019-12-12 00:00:00
The only way to fix it is to add 'T' between date and time
DECLARE #t DATETIME2 = '2019-12-12T00:00:00'
At the same time, this script runs perfectly fine at my production server (without adding 'T').
I tried to find the difference and don't see anything that could affect the behavior:
Collation is the same at both servers - SQL_Latin1_General_CP1_CI_AS
Language is the same - English (United States)
Server version: LOCAL is Microsoft SQL Server 2017 Developer Edition (64-bit) v14.0.2027 RTM; REMOTE is Microsoft SQL Server 2017 Enterprise Edition: Core-based Licensing (64-bit) v14.0.1000 RTM
Host OS: LOCAL is Windows 10 Pro; REMOTE is Windows Server 2016 Datacenter
Can somebody explain, why I'm getting the error locally?
This is a client-side error so it seems you are running the query from SSMS with the Enable Always Encrypted (column encryption) option for the connection (connection Options-->Always Encrypted) on the remote client but not the prod server. With the option enabled, the SSMS client parses literals in order to build parameters for AE.
Unlike '2019-12-12 00:00:00', the ISO 8601 datetime format literal '2019-12-12T00:00:00' is unambiguous and can be reliably parsed regardless of the client regional settings.
So your options are to either use an ISO 8601 datetime format or turn of the SSMS Enable AE option for the connection.
Related
There is some kind of pre-processment of the SQL text on FireDAC queries that truncates their string literals containing ! characters.
It's very easy to replicate:
Place a TFDConnection, a TFDQuery connected to the connection, a TDatasource connected to the query and a TDBEdit connected to the datasource.
After setting my server configuration on the TFDConnection, if I try this SQL on the TFDQuery : Select 'Hel!o World' as column, I would only see He on the TDBEdit instead of Hel!o World.
It's a problem of FireDAC because the same query runs fine directly on SQL Server Management Studio.
Is there a way to fix o disable this pre-processment of FireDAC ?.
It's Delphi 10.4 and SQL Server 2017 accessed by SQL Server Native Client (I have also tried the same query on Delphi 10.3 and returns the same error).
Thank you.
We are installing a new application, the pre-requisite of which says that your database must be configured to use the UTF-8 character set.
We are currently using SQL Server 2016, enterprise edition.
Our database team mentioned to us that SQL Server doesn't support UTF-8 and have suggested to use nChar and nVarchar datatype for UTF-8 character set support.
I am not a database expert unfortunately. Could someone please help understand what exactly could be done here?
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 SQL database (2012) that I am trying to access through R (R Studio). From Enterprise Manager this is what it looks like:
select top 5[date],value from dbo.history
1991-02-11 11.1591
1991-02-12 11.2
1991-02-13 11.3501
1991-02-14 11.37
1991-02-15 11.3002
However from R this is what I get:
sqlQuery(DF_CN,'select top 5 [date],value from dbo.history')
date value
1 0011-02-19 11.16
2 0012-02-19 11.20
3 0013-02-19 11.35
4 0014-02-19 11.37
5 0015-02-19 11.30
When I try and select all the data from the table, this is what I get
sqlQuery(DF_CN,'select * from dbo.history')
Error in charToDate(x) :
character string is not in a standard unambiguous format
It may to be something about the yyyy-mm-dd default format from SQL server which I can change if I use CONVERT, but this looks like a hack and the SELECT * would not work.
Is there something in R I can do to recognise the SQL Server dates?
Ben
This is driving me nuts - surely someone has seen this before - there is a clear disconnect between the SQL Server output and what R is reading.
I am using RStudio 0.98.1091 and R x64 3.1.2.
Sql Server 2014
Microsoft SQL Server Management Studio 12.0.2000.8
Microsoft Data Access Components (MDAC) 6.1.7601.17514
Microsoft MSXML 3.0 4.0 6.0
Microsoft Internet Explorer 9.10.9200.17148
Microsoft .NET Framework 4.0.30319.18444
Operating System 6.1.7601
ODBC Driver 11 for SQL Server.
Everything looks up to date on my system.
the [date] column was of type DATE, is now DATETIME. I now get this;
sqlQuery(DF_CN,('select * from dbo.history')
Error in as.POSIXlt.character(x, tz, ...) :
character string is not in a standard unambiguous format
It looks like some disconnect between SQL server setup and R setup.
I worked it out by using the as.is parameter:
sqlQuery(DF_CN,'select * from dbo.history',as.is=T)
Then casting the values I needed directly in R.
I have worked it out.
Driver set to SQL server Native Client 11.0
ODBC settings - Use regional settings when outputting currency, numbers, dates and times switched off.
I am thinking that SQL Server has its own ideas on regional settings rather than what has been provided by windows causing great confusion.
I have a SQL Server 2012 database with an Access 2007 front-end. My problem is that Access does not recognise SQL Server's dates as they are in a different format.
SQL Server-s format is YYYY-MM-DD
Access' format is DD-MM-YYYY
When the date is displayed in a text-box, it is displayed as a string (without the little calendar icon next to it).
Is there anyway I can configure my Access front-end so that it recognises SQL Server's dates?
I used Microsoft SQL Server Migration Assistant for Access to migrate the data into SQL Server
As this DB is in development I have the SQL Server on my local machine in C drive (no virtual drives)
From my research I have found this answer:
The problem the user has encountered is with a Driver. Microsoft has a new DLL that must be put on a client
workstation (or server in the case of Citrix). Once that is done, all the dates in MS Access will work
properly. My lastest experience with Access 2010 was exactly the same as Access 2003.
It required a DLL. From there, investigate using a DNS-Less connection string
Where would I find this DDL driver and how would I install it.
Thanks
Maggs
I found that SSMA for some reason converted all the datetimes to datetime2. I went into SQL Server Management Studio and changed them to datetimes and it fixed the issue. You could also check the field mapping in SSMA and adjust it before migrating.
(I have the exact same environment - SQL Server 2012 and Access 2007, using SSMA.)
I am using SQL Server 2012 on my local PC (Vista) and have an Access 2010 frontend with ~75 linked tables.
The table in SQL Server has a column named 'EnteredDate' that is defined as 'datetime'.
In Access the 'EnteredDate'column is defined as 'Date/Time'.
In Access, I just ran the following query with proper results:
SELECT DataError.Description, DataError.EnteredDate
FROM DataError
WHERE (((DataError.EnteredDate) Between #1/1/2010# And #1/31/2010#));