We recently moved our database from SQL Server 2005 to 2014. But now we are having an issue with how the server converts datetime from varchar.
Previously, a date string 2017-06-30 was converted correctly as July 30, but now even with the user and the database with the language set to Spanish, it still converts the date format as yyyy-dd-MM.
Is there some way to permanently change the configuration to fit the original one? One work around we found was to add SET LANGUAGE ymd at the beginning, but the amount of procedures doesn't make this feasible in a timely manner.
Related
I'm migrating data from DB2 for Z/os (Mainframe) to RDS distribution of SQL Server.
In the mainframe, the date is stored in EURO format which is DD.MM.YYYY, when I migrate the data to SQL Server, the data is stored in SQL Server in YYYY-MM-DD ISO format.
All of my application program expects the date to be in DD.YY.MMMM format. I know I can use convert function at application programs to format the date to convert to EURO format. There are thousands of programs which would require change if I take that route.
Is there a way I can enforce SQL Server to store the date in DD.MM.YYYY or DD/MM/YYYY format ?
I already tried changing the Default Language of SQL server to "British English" it doesn't seem to be of any help. When I issue "DBCC USEROPTIONS" it shows Language as "BRITISH" and Date as 'dmy' but still when application program retrieves the date it's in yyyy-mm-dd format only.
My application program connects to SQL Server via ODBC driver and I have tried changing the OS Date from Control panel as well of dd/mm/yyyy format. Any advice on this issue will be of great help.
Thanks in advance!
I already tried changing the Default Language of SQL server to "British English" it doesn't seem to be of any help. When I issue "DBCC USEROPTIONS" it shows Language as "BRITISH" and Date as 'dmy' but still when application program retrieves the date it's in yyyy-mm-dd format only.
If you want to guarantee that that dates are returned as dd.mm.yyyy, then you can convert them to a string:
select convert(char(10), datecol, 104)
In SQL Server, you can handle this by using views or adding computed columns to the tables:
alter table d add datecol_ddmmyyyy as ( convert(char(10), datecol, 104) );
Otherwise, the application should be able to ingest SQL Server dates in the native format. This is only relevant if they are being converted to strings.
I have the requirement for dates that predate 1753, the minimum for datetime on SQL Server. DB-side, the solution is clear: change to datetime2 format. But it seems Informatica still treats the column as datetime. I suppose datetime2 is not supported. Is there any workaround that could enable me to insert pr-1753 dates in a datetime2 column?
Informatica version is 9.1.0, SQL Server 2008
If upgrading to a newer version of Informatica won't help or isn't an option, then you've got limited options. One option is to CONVERT the datetime2 to a suitable VARCHAR representation from the SQL Server side and then feed that to Informatica and let the implict casting of the value back to a suitable DATETIME do the hard work for you.
You'll need to make sure you are very careful with this though - if you end up migrating text dates such as 02/03/2015 02:33 etc - then there's a chance that if regional settings differ between databases or servers, you could import that as either 2nd of March or 3rd of Feb. It's best to use culture-invariant date formats, such as yyyy-mm-dd - that way it's always unambiguous.
-Steve
I am developing a VB.Net application that has operations which rely heavily on dates & times. As there could be conflicts on date formats if the application date format doesn't match the server date format what is the best practice to resolve this issue. I know that SQL Server datetime format depend on the server language & VB.Net will use the local machine datetime format. Which means if a user changes the datetime format it will cause problems when inserting.
My idea is to use SELECT GETDATE() on application startup, then identify its datetime format using VB.Net & whenever I try to insert a datetime value I will convert it to the datetime format identified at the application startup.
Is there a better approach to having a consistent datetime formats between the application & SQL Server to avoid comflicts. eg: Mixing a day with a month.
SQL Server doesn't store a DateTime in any string format - it's stored as an 8 byte numerical value.
The various settings (language, date format) only influence how the DateTime is shown to you in SQL Server Management Studio - or how it is parsed when you attempt to convert a string to a DateTime.
There are many formats supported by SQL Server - see the MSDN Books Online on CAST and CONVERT. Most of those formats are dependent on what settings you have - therefore, these settings might work some times - and sometimes not.
So if ever possible, don't convert dates between DateTime and string all the time! Leave it as DateTime in .NET, use DATE or DATETIME2(n) in SQL Server, and let the dates be in their native format. Use parametrized queries that support the native DateTime datatype so you don't need to convert dates to string and back!
If you must use strings to represent dates for whatever reason, the only reliable way to solve this is to use the (slightly adapted) ISO-8601 date format that is supported by SQL Server - this format works always - regardless of your SQL Server language and dateformat settings.
The ISO-8601 format is supported by SQL Server comes in two flavors:
YYYYMMDD for just dates (no time portion); note here: no dashes!, that's very important! YYYY-MM-DD is NOT independent of the dateformat settings in your SQL Server and will NOT work in all situations!
or:
YYYY-MM-DDTHH:MM:SS for dates and times - note here: this format has dashes (but they can be omitted), and a fixed T as delimiter between the date and time portion of your DATETIME.
This is valid for SQL Server 2000 and newer.
If you use SQL Server 2008 or newer and the DATE datatype (only DATE - not DATETIME!), then you can indeed also use the YYYY-MM-DD format and that will work, too, with any settings in your SQL Server.
Don't ask me why this whole topic is so tricky and somewhat confusing - that's just the way it is. But with the YYYYMMDD format, you should be fine for any version of SQL Server and for any language and dateformat setting in your SQL Server.
The recommendation for SQL Server 2008 and newer is to use DATE if you only need the date portion, and DATETIME2(n) when you need both date and time. You should try to start phasing out the DATETIME datatype if ever possible
I transfered data from our old SQL Server 2000 (SBS 2003) to another server running SQL Server 2008 r2 (Server 2008 r2 standard).
The data was transfered, but now the dates in the different tables are messed up.
Is there a special procedure I need to follow in order for the date column to transfer correctly. If memory servers, date columns are soted as an offset.
Anyone know how to correct this?
I tried looking it up, but couldn't find an answer. Maybe I just didn't think of the correct key words.
Thanks!
Edit: What I mean by messed up is that the original date (from the old server) is 2011-05-08 and the new date (from the new server) is 2010-04-14. I tried to see if there is a common offset for all he moved dates, but couldn't find one.
Are you sure you don't have the Old (2011 dates) / New (2010 dates) backwards? It sounds like you just aren't including the date column in your INSERT, and it has a default of GETDATE(), so it has the current date getting inserted. Or there is some trigger changing the value from what you specify to the current date. To verify, do your SELECT..INSERT into a new or temp table and see what you get.
I am using SSIS 2005 to read data off a .csv file into a SQL Server 2005 Database. I am using a Flat File connection manager for the .csv and an OLEDB Connection Manager for the resulting rows.
The .csv file contains a field which is a date in UK format (dd/mm/yyyy), which may be written, say, 7/3/2011 for 7th March 2011. This column is then mapped onto the equivalent datetime field in the SQL Server database.
The problem I am facing is that, while everything works fine on the development machine, when used on the production environment, the dates get changed to US (mm/dd/yyyy) format (if valid), when they are inserted into SQL Server. Is there some place where the desired Region/Format (in this case UK) for the destination datetime field can be specified, maybe somewhere in the package or some setting on the production server itself?
Thanks in advance,
Tim
You can set the locale in the Flat File Connection Manager Editor or LocaleID in the Properties box for the connection (same thing). Setting it to "English (United Kingdom)" will interpret the dates correctly, because SSIS uses the locale in the package or data flow, not the OS locale.
Note that you have to set the format at the source, not the destination: datetime is a binary format in MSSQL so dates aren't stored internally in a locale-specific format anyway.