Last post Aug 22, 2007 09:41 AM by RTernier
Aug 21, 2007 05:37 PM|RTernier|LINK
I'm having issues working with Cultures and DataBase updates/inserts.
I'm setting my culture Via:
protected void SetCulture(string name, string locale)
Thread.CurrentThread.CurrentUICulture = new CultureInfo(name);
Thread.CurrentThread.CurrentCulture = new CultureInfo(locale);
Session["Culture"] = Thread.CurrentThread.CurrentCulture;
And this works fine, the site displays everything correctly. The problem I have is when I run this function:
public static String ToSQLValidDateTime(object TimeDate)
if (TimeDate == null)
return "'" + Convert.ToDateTime(TimeDate).ToString("dd MMM yyyy hh:mm:ss tt") + "'";
If I use a ca-FR culture (Canadian French) the date returned will be in french, which will cause some Queries to fail.
What can be done to resolve this? Any advice would rock. Thanks.
Aug 21, 2007 06:28 PM|Mikesdotnetting|LINK
Aug 21, 2007 06:29 PM|mystery|LINK
It is not necessary to convert the DateTime object to SQL string. The best way to use DateTime in SQL query is to use SqlParameter - it will do the conversion for you.
Provided you wan to insert the obect myDate of type DateTime you should use the following code:
SqlParameter dateParam = new SqlParameter("@dateVar", myDate);
then you can add this parameter to your command object and use @dateVar in your query.
Aug 21, 2007 11:09 PM|rstrahl|LINK
Is there any reason why you are using strings to format the dates? If you're posting this stuff to SQL a SQLPparameter will automatically format the date properly for you regardless of culture.IOW, let .NET do the work for you [:)]
IAC, you can use an explicit culture when using ToString() as the second parameter - preferrably CultureInfo.Invariant:
You can also CultureInfo.InstalledCulture which will be the server's 'native' language regardless of the thread culture mapping.
The same applies if you provide a format string.
Hope this helps,
+++ Rick ---
Aug 22, 2007 09:41 AM|RTernier|LINK
As for the reason why we use strings? No idea. It's just the way we have always done it since I got here. I've since re-vamped the connection class to use param Parameters... I'll switch it to that.