Does anyone know how you can get SQL Server 2005 Express to NOT install as US English?
All my win2k8 Regional Settings are set to English(New Zealand) but it always installs as US English.
I can't find anywhere to change it in the installer.
Okay, so date formats are the problem. So you mean your application is trying to insert dates something like this:
insert into Table1 (DateField1) values ('31/3/2008')
which fails because it thinks "31" is the month? Yeah I get that problem too in Australia. Your choices are:
1) Change the default language of the database, and the language for existing users. The language is actually configured on a per-login basis, so for example is SQL Management Studio, Security --> Logins, right-click a login, go to Properties, and change the "Default language" from English to British English. To ensure this also occurs for all new users, you need to change the default language of the server, which is done with:
select * from sys.syslanguages
.... then find the language you're looking for, i.e. British English and note the langid. To set it, say if British English has langid = 23:
sp_configure 'default language', 23
go
reconfigure
go
2) Make your application do date selects/inserts using an appropriate convert i.e.
insert into Table1 (DateField) values (convert(datetime, '31/3/2008', 103))
select DateField1 from Table1 where DateField1 = convert(datetime, '31/3/2008, 103))
3) Make your application do date selects/inserts using an international format. From BOL:
We recommend that you use date-time
formats that are not DATEFORMAT
dependent and are multilanguage. The
ISO 8601 formats,
'1998-02-23T14:23:05' and
'1998-02-23T14:23:05-08:00' are the
only formats that are an international
standard. They are not DATEFORMAT or
default login language dependent and
are multilanguage.
I'm guessing that in this case you can more easily change the database than the application, but if that's not the case then you should really make the application do things in a more global way. App/database design should try to be format-independent where possible.
Related
I'm trying to work with a 3rd party application which stores dates (can be entered by the user, in some cases with little validation) in a varchar column, then uses CONVERT( DATETIME, MY_COLUMN ) - without an explicit format - when it wants to use them as dates. Ugh.
Unsurprisingly this often fails. But not always. What is SQL's default format for CONVERT if you don't specify one? It appears to be 101 (i.e. mm/dd/yyyy), but is this always the case? Does it depend on the database or server collation or some other setting? The MSDN CAST and CONVERT docs don't say.
We're using SQL Server 2014.
For the default, it depends on the default language setting at the server or login level, which implicitly sets the dateformat, datefirst, as culture related settings. You can also change the defaults based on login. e.g.
alter login [aucuparia] with default_language=[british];
These can be changed at the session level with set language, set dateformat, and set datefirst.
To see the language setting for the current connection:
select ##language;
To see settings for each language:
select langid, alias, DateFormat, DateFirst, months, shortmonths, days
from sys.syslanguages;
The problem in short: The same database returns dates in a different format on different servers and I'm having trouble to configure it to correct date format.
I have the following situation:
A PHP-based web application that gets it's data from Microsoft FoxPro 9 databases.
The database connection is made with OleDB. In PHP this utilises ADODB through COM objects:
$this->connection = new COM("ADODB.Connection");
$this->connection->Open($this->connectionString);
The connection string looks like this:
Provider=VFPOLEDB.1; Mode=Share Deny None; Window Handle=0;
Locale Identifier=1033; Prompt=4; Extended Properties=0;
User ID=; Password=; Mask Password=False; Cache Authentication=False;
Encrypt Password=False; OLE DB Services=0; Collating Sequence=MACHINE; DSN=;
DELETED=True; ENGINEBEHAVIOR=80; TABLEVALIDATE=0;
Data Source=\\path\to\file.DBC
The program is deployed on different servers throughout the world, running on different versions of Windows Server (2003-2008 R2). Query's are executed the following way:
$this->connection->Execute($query);
This returns a resultset with all values in plaintext. This is where the problem arises. The databases don't use the same formatting for dates, which makes it difficult to process the dates later on in PHP.
So far, the app can cope with the US format: mm/dd/yyyy and the dutch format: dd-mm-yyyy. The program just assumes that when the date contains slashes the US format is used and when there are hyphens the d-m-y format is used.
This has been going fine for a long time, but now we recently deployed the program to a server in Brazil, which returns dates in the Brazilian format dd/mm/yyyy. The program obviously now confuses this with the US format.
I've been trying to get the database to report in a different date format (US) to no avail.
On two different dev-environments, changing the Regional settings of windows to a different country immediately alters the date-format the database uses. These dev-environments are all Windows 7 systems.
However, this won't work on the servers with Windows Server. I have changed around all of the Regional settings (Formats, Location and System locale) on multiple servers without any results. Even after rebooting or reïnstalling FoxPro with the correct regional settings. The databases keep reporting in the date-format they seem stuck in.
Does anybody know how I can change the date-format used by FoxPro on a Windows Server environment?
Other options I have explored include putting regional information into the DSN, but couldn't I find any possible way. Also the FoxPro statement SET DATE TO ..... is not accepted through OleDB.
Altering the application to understand the Brazilian format or to add a bunch of if-else statements doesn't seem like a feasible solution.
The FoxPro date type is date-format-insensitive. That is, if you simply return the value as a date (datetime) rather than converting to character, you shouldn't have any problems.
Wrap your FoxPro date field the DTOC function, with the second optional parameter. This will return a standard YYYY-MM-DD style date, regardless of regional setting.
SELECT DTOC(dDate) as dDate FROM Alias
If that's not feasible, you'll need to investigate the functions to explicitly set a locale in FoxPro, such as the intuitively named SYS(3005).
And if even that's not feasible, you'll need to resort to requiring servers in foreign countries to have their regional settings standardized at the OS level.
Maybe be explicit in your query and handle reconstructing the date within the web application. So if you have a date-type field in VFP called MyDate then do:
select x, y, z, day(MyDate) as daynum, month(MyDate) as monthnum, ;
year(MyDate) as yearnum from mytable
OK, so it's more work on the other reconstructing a date from that but at least it should be location-agnostic.
It seems this question is asked a lot, but none of the answers have given me results. I'm pulling my hair out here ... so hopefully someone has an answer.
I have a production server running SQL Server 2005. I backed up the db and restored it on my laptop's SQL Server Express instance. Now date queries are seriously affected. In the prod. server they are all stored as "4/13/2011 12:00:00 AM" format, but on my laptop they are showing as "2011-04-14 00:00:00.000". When I do a query trying to find entries on "4/14/2011" my laptop gives me the error "The conversion of a varchar data type to a datetime data type resulted in an out-of-range value". Edit: This exact query runs fine on the production SQL server. (I'm using SSMS to run queries ... not an application/code)
I made sure my laptop's Windows regional settings are the same as the server (English(United States)) and everything on the Region and Language control panel is the exact same.
Finally I ran the following two queries:
select name ,alias, dateformat
from syslanguages
where langid =
(select value from master..sysconfigures
where comment = 'default language')
select ##language
Which gave the result of "*us_english, English, mdy*" ..... and "British" respectively. Where is this British coming from?! Now when I run this command before my query (in the management studio)
SET DATEFORMAT mdy
Then everything works perfectly! But in the syslanguages query it seems to already be mdy format. I'm not about to rewrite my application with "SET DATEFORMAT" all over the place - so hopefully someone has a clue. Maybe my SQL Express installation is buggared and I have to reinstall it?
I'm going to keep tinkering to hopefully get this to work.
It is the language settings of the login that you need to change.
You can do it through SSMS -> Security -> Logins -> YourLogin -> Properties -> Default Language
Or through TSQL
ALTER LOGIN [YourLogin] WITH DEFAULT_LANGUAGE=[us_english]
If you specify things in dd-mmm-yyyy format, or better still, use DateTime parameters (rather than varchar input), you won't have a problem.
Try changing the default language to us-english, using the following:
EXEC sp_configure 'default language', 1033
RECONFIGURE
If that doesn't work, you could try language code 0.
Are you passing dates as string literals - or concatenating strings to build up the sql in your application?
If you are doing this, consider using parameters for the dateTime data types. Or at least escape them using the ODBC escape clause and format them as in { ts'yyyy-mm-ddhh:mm:ss[.fff] '} such as: { ts'1998-09-24 10:02:20' }.
It is most probably your application not passing the datetime properly.
Since yesterday I started encountering errors related to date formats in SQL Server 2008.
Up until yesterday the following used to work.
EXEC MyStoredProc '2010-03-15 00:00:00.000'
Since yesterday I started getting out of range errors. After investigating I discovered the date as above is now being interpreted as "the 3rd of the 15th month" which will cause a out of range error.
I have been able to fix this using the following format with the "T".
EXEC MyStoredProc '2010-03-15T00:00:00.000'
By using this format its working fine. Basically all I'm trying to find out is if there is some Hotfix or patch that could have caused this, as all my queries using the first mentioned formats have been working for months.
Also this is not a setting that was changed by someone in the company as this is occurring on all SQL 2005/2008 servers
The language setting of the session can change this.
--This works
set language english
select cast('2010-03-15 00:00:00.000' as datetime)
--This doesn't
set language french
select cast('2010-03-15 00:00:00.000' as datetime)
With the T in between, it always works. If you want a space, then leave out the hyphens.
--This works
set language english
select cast('2010-03-15T00:00:00.000' as datetime)
--This works
set language french
select cast('2010-03-15T00:00:00.000' as datetime)
--This works
set language english
select cast('20100315 00:00:00.000' as datetime)
--This works
set language french
select cast('20100315 00:00:00.000' as datetime)
So my guess is that your app has changed... or some setting on your client computer.
To avoid these kind of problems you should always specify your date format. For your purposes you should use:
SET DATEFORMAT ymd;
See this MSDN page - note the comment that
ydm is not supported for date, datetime2 and datetimeoffset data types
so you might have to use a different format if you're using one of those data types.
It sounds like you've got a mixture of date styles - yyyy/MM/dd vs yyyy/dd/MM - which seem to be reverse UK and US style dates.
If all servers are showing the same behaviour it could be that just the machine executing the code has changed rather than the other machines/SQL servers in the network.
Double check that the date format or indeed culture settings are what you expect them to be on that machine. Assuming they weren't you might be able to find out what changes to the machine were made over the weekend from the event logs or Windows Update history.
Collation can effect dates, as well as the language.
To check what default language a server has installed, use the following SQL command:
sp_configure 'default language'
If the resulting value is 0, the default language U.S. English. If the result is not 0, run the following SQL command to find the installed default language setting and date format used:
select name ,alias, dateformat
from syslanguages
where langid =
(select value from master..sysconfigures
where comment = 'default language')
NOW as to the system updates updates, those were in 2007 to adjust to the DST changes mandated back then.
Machine specific: you CAN set the clock on a specific machine to NOT adjust for DST - check that setting per machine (Windows it is on Control Panel/Date and Time under XP for instance).
IF you choose to use the dashes, you may have issues in dates. If you take out the dashes, SQL Server will never misinterpret the data:
EXEC MyStoredProc '2010-03-15 00:00:00.000'
this is likely getting a time with a negative hour offset, which is in this case invalid.(just a guess)
vs
EXEC MyStoredProc '20100315 00:00:00.000'
Note that the T in there is the ISO8601 format, and thus the dashes are allowed.
Ok I just read a post over at Simons SQL Blog (http://cli.gs/hqaR4) about this specific issue. So one solution to this problem is to Use the new DATETIME2 datatype as it understands languages that doesn't use MDY dates
In my application we have to call SET DATEFORMAT YMD before each and every operation. In the master.dbo.syslanguages in entry for my language (polish, lcid=1045) there is dmy format.
So is there any way I could change this entry or create a new language that will be like old one, but with changed DATEFORMAT?
SQL Server 2005 removed the option to update system tables that was present in SQL Server 2000 (using sp_configure 'allow updates', 1)
Can you not change your client date format so it's recognised correctly regardless of DATEFORMAT settings? eg 4 figure year, ISO formats etc such as (not exhaustive) "21 feb 2008 14:32", "2008-02-21 14:32", "20080221 14:32" etc.