Thanks for all the help from everyone so far, I'm not quite out of the
woods yet tho!
[quoted text, click to view] "Allan Mitchell" <allan@no-spam.sqldts.com> wrote in message news:<4107c9f7$0$7125$db0fefd9@news.zen.co.uk>...
> Make sure the SQL Server user is a UK English User otherwise SQL Server will
> do this
>
> (presume user language is set to English (American))
The database user (a pure SQL Server user) was set to English. I
found another language called "British English", I've changed that
user to British English and now I can input dates in a UK format
(DD/MM/YYYY) which is great, thanks for that. I appreciate the 'best'
way to do it is to use an ISO format but my users wouldn't cope with
such technicalities as this...
However, dates *returned* are still in US format (MM/DD/YYYY)! Is
there some other esoteric setting I have to tweak somewhere?
[quoted text, click to view] > This guy is American so he is giving me a date of 25/12/2004. Americans use
> MMDDYYYY so what he means is
>
> the 12th day of the 25th month
>
> this as we can guess is way out of range.
>
>
> Here is another example
>
> SET LANGUAGE us_english
> GO
Won't that set it for the all databases on the whole server? We have
a number of applications that use the SQL server for their databases,
some of which may well have been developed in the states. If I change
the setting for the whole server, any other applications that don't
use the ISO or other non-regional date formatting will break surely?
[quoted text, click to view] > select cast('25/12/2004' as datetime)
Tried this also, didn't make any difference.
[quoted text, click to view] > Changed language setting to us_english.
> Server: Msg 242, Level 16, State 3, Line 2
> The conversion of a char data type to a datetime data type resulted in an
> out-of-range datetime value.
>
> SET LANGUAGE British
> GO
>
> select cast('25/12/2004' as datetime)
>
> 2004-12-25 00:00:00.000
>
> --
> --
>
> Allan Mitchell MCSE,MCDBA, (Microsoft SQL Server MVP)
>
www.SQLDTS.com - The site for all your DTS needs.
>
www.konesans.com - Consultancy from the people who know
>
Niall Porter (niallporter@yahoo.co.uk) writes:
[quoted text, click to view] > However, dates *returned* are still in US format (MM/DD/YYYY)! Is
> there some other esoteric setting I have to tweak somewhere?
I'm still not sure why you post this in an SQL Server forum, I would
expect this to be an ASP problem. Then again, since you have not posted
any code, I have no idea of what you are doing.
[quoted text, click to view] >> SET LANGUAGE us_english
>> GO
>
> Won't that set it for the all databases on the whole server? We have
> a number of applications that use the SQL server for their databases,
> some of which may well have been developed in the states. If I change
> the setting for the whole server, any other applications that don't
> use the ISO or other non-regional date formatting will break surely?
SET LANGAUGE changes the language for the current session. However, this
option controls how date literals are interpreted on *SQL Server* and
you got the conversion error on client level.
--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
Books Online for SQL Server SP3 at
Allan Mitchell (allan@no-spam.sqldts.com) writes:
[quoted text, click to view] > If the client connects as a US user on a UK server entering a data of
> '25/12/2004' then wouldn't the error returned be this error. My
> expereince of mixing regional settings says it would.
Depends. The error Neill got was:
Microsoft OLE DB Provider for SQL Server (0x80040E07)
The conversion of a char data type to a datetime data type resulted
in an out-of-range datetime value.
The only way to get that error from Query Analyzer is to connect a linked
server with a date-format conflict along the line.
The problem here is that things can to wrong on several levels. In Neill's
case it got wrong already on client level. I suspect because he was
using adDBTimeStamp to which he must feed an ISO format.
It is also confusing since the regional settings on the client neither the
server on what happens in SQL Server which uses its own language
definitions. You can set language when you connect, but then you have to
pass that in the connection string - and it has to be a language as SQL
Server knows it.
The main problem in Neill's case is that he has not posted any code, so
we are left to guessing.
--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
Books Online for SQL Server SP3 at