Date/Time erros when working with Database Connectivity toolkit

Question

Hi!,
We are observing errors with date/time when working with LV. The error occurs when the system datetime format is set such that day precedes month (e.g. dd/mm/yyyy). Our VI uses LV 7.1, Database Connectivity 1.0 and SQL Server 2000 on a Win2000 machine.
Problem details
Our database in SQL server has a table having columns with data type "datetime"
If the system date format (as set in control panel) is "mm/dd/yyyy", the 'insert into database' vi works fine. This function inserts the date and time (among other things) into the above mentioned table.
However, when the system datetime is set to dd/mm/yyyy we start receiving error that date and time is beyond range for dates in which the date had the day field greater than 12 (e.g. 23/10/2005). With the same settings, if the date is such that day field is equal or less than 12 (e.g. 03/10/2005), we do not receive an error but the date is interpreted as 10 March 2005 rather than 03 September 2005.
Clearly LV (or is it SQL) is mistaking the day field as month.
We have taken care that when sending and receiving date, the format date and time string is set as per system settings.
Thus, if system setting is "dd/mm/yyyy" our format string is "%d/%m/%Y"
And if the setting is "mm/dd/yyyy" our format string is"%m/%d/%Y"
Any help on problem cause and cure is welcome.
Thanks,
Gurdas
Gurdas Singh
PhD. Candidate | Civil Engineering | NCSU.edu

Answer 1

Hi Xu,
You answer led me to some very interesting fact finding on how SQL server handles date and time. I have attached a zip file which contains webpages that throw more light on this issue.
The attached pages tell me that SQL has an inbuilt date/time reference format. The default in mm/dd/yyyy. Which explains why my VI worked when I used that format to write to SQL.
However there is a catch:
SQL expects the date/time to be in its inbuilt reference format when you WRITE data to SQL. If the date/time is in a different format, better tell SQL about it by using say the SET command you mentioned.
BUT what about the date/time format when you are reading data from SQL?
Our finding is that SQL sends date/time string in the system date format when you READ from SQL !!! That is very surprising behaviour (why differentiate between write and read?).
Is our finding correct?
So, we adopted the following simple strategy (yet to be fully tested):
1) Whenever we write date/time to SQL, the string is formatted as mm/dd/yyyy. Presently, the user's SQL server is in the default state. Caveat is that if the user changes SQL date/time from default (which is mm/dd/yyyy) to anything else, our software will give errors. But then he changed it  ;-)
2) When we read date/time from SQL we format the string as per system date/time format.
I know this is not very robust coding. But assuming the user keeps his SQL in the current setting, should we expect smooth working?
In other words, are there any errors and/or flaws in our strategy?
Thanks,
Gurdas
Gurdas Singh
PhD. Candidate | Civil Engineering | NCSU.edu