DateTimePicker problem

[Chris Beharry]

Hi this is a strange problem which only occurs on one computer in our office.

I have a DateTimePicker in my C# application and it works properly on everyone's computer (except one) to select specific dates.

I noticed that on the one problem computer that when the DateTimePicker is used it sets the date a little different that on working computers.

His looks like this once he uses the calendar:
'February -14-12'

Mine looks like this:
'Tuesday , February 14,2012'

Once he selects a specific date the above shows up but an exception arises:
System.Data.SqlClient.SqlException: Conversion failed when converting date and/or time from character string.

This is the only code I can think of to submit:

dtpAppts.Value.ToShortDateString()

This is a C# Winform application running against a SQL DB. VS 2010 pro / Framework 3.5.

I understand the cast problem above but why wouldn't an else have the same problem? My thoughts point to a local system problem but he's using the same OS and setup as everyone else (Windows 7 pro with SP1).

I have a feeling it's not a problem with the C# coding but a problem with the querry, or how C# is interpreting it...or something like this. Strange though, only on one computer?

Does anyone have any thoughts?

Thanks very much,

~ Chris

[GaryTexmo]

Did you check his region settings? If it's Win7, go to Control Panel and select Region and Language. Check to see if his date and time formats differ from yours.

[Chris Beharry]

I checked today and it was exactly the same as mine.
Good thought though.

Any other thoughts?

Thanks,

~ Chris

[GaryTexmo]

Darn... that's usually the culprit. He's running an executable you built right, so it should work.

If you're able to, set up remote debugging and see if you can debug his application from your computer. Perhaps then you can set some breakpoints and find out what your datetimes are getting set to or even what the program thinks it's CurrentCulture setting is (in case it's telling the OS to take a hike and doing it's own magic).

Failing that, I'd suggest perhaps giving him a special debug build of your application that will output to a log file so you can get a better picture of what's happening behind the scenes.

[Chris Beharry]

You actually had it correct.
Well I'm happy to say it’s fixed but somewhat embarrassed too…
I completely neglected to try to replicate the problem from my home machine ..a Win 7 machine.
Perhaps I should have also mentioned that … I'm in Canada!

The problem was that my colleague and I had our settings set to English (Canada).
While I compared my settings at home to my colleague I realized today that I actually never tried the DateTimePicker from home (it just never came up), I use it at work where I still use an XP system.

Thanks again for your input, I appreciate it but it does bring up one question:
Is there a way to get .net to no matter what date format or setting it is, convert it to a format the application uses (US English)?

This is the code I have:
and CAST(MyDate AS DATE) = CAST('" + dtpMyDates.Value.ToShortDateString() + "' as DATE)
dtpMyDates.Value.ToShortDateString() is the DatetimePicker .net part and everything else on the outside is MSSQL (the database I'm getting my dates from).

I'll try ToLongDateString() ....etc and post my results.

Thanks again,

~ Chris

[GaryTexmo]

Well, you can override the system culture settings if you want... I think it's Thread.CurrentThread.CurrentCulture, or something to that effect. You can change it. You can also specify a culture when you do DateTime conversions (or number format conversions for that matter).

That said, it's generally best if you let your program deal in the culture that the system is set to. As long as you're not crossing cultures you're ok... but it does sound like you are.

That code you posted... is that SQL? If so, the yea you might want to give the "en-US" culture format specifier when you convert it to a string, assuming you're going to make sure all your database entries are in the US date format.

One final thing... I notice you're using string concatenation for building your SQL string. This is pretty dangerous as it leaves your code open to SQL injection attacks. You should look into using parameterized queries instead. If any of that is confusing and you'd like more information, please feel free to post another topic to look into it, just so we can keep information organized around here :)

[Chris Beharry]

Sorry for the tardy reply, life keeps us really busy doesn't it?

Thanks for the input GaryTexmo I'll give the code a try when I get a chance.

Yes it's SQL. The app I'm working on is only available via the internal network and it's only accessable via secure, encrypted login. That said you do have a point and I will heed your advice. I'm a little new at coding like this and unfortunately there's no one to look over my shoulder to guide me and point me to proper coding...I guess that's what brings me here.

I'll be eventually setting this up as am intranet site and possible acessable via the web so I'll definitely have to do it properly then.

Thanks again,

~ Chris