tags:

views:

58

answers:

4

Hello, I use the UPDATE statment in order to update a Date\Time field. i use the Date.Now.ToShortDateString() statement. when i run in debug mode i see that the value is for example "18/09/2010". then, when i open the Data Base i see that the value that was insert is "09/18/2010".

Does anyone know how can i fix it? (i later display this date field in my GUI so i need it to be in the right way)

Thanks,

Tamar

A: 

This is a culture problem of your application. Too bad as far as I know access doesn't support changing the culture of its database. Change the culture of the application to en-US or even better use UTC dates and convert them to the right culture in your application when you want to show them.

RonaldV
If the database has to be used from computers with different regional settings, that wouldn't work, even if it were possible. It's the responsibility of the programmer to handle string representations of dates correctly, in a way that produces predictable results when interacting with the database but that also is correct in the presentation layer so that users see dates in expected formats. All databases exhibit this issue to some degree because none of them use the same string representation for storing dates that we as human beings depend on for comprehensibility.
David-W-Fenton
You might want to read what I said again. Because that's exactly what I'm saying. Store the date/time in the database as UTC date and show them in the correct culture when showing them in your client.
RonaldV
Your comment "store the date/time in the database as UTC date" is nonsense, as Jet/ACE doesn't store date as any particular string representation. There are no database regional settings (as you lament), and my point was that this wouldn't solve the problem even if there were. The current implementation is the best, and you're right that the correct solution is to set the regional settings dynamically in your application, according to those of the user.
David-W-Fenton
A: 

Use parameters instead of concatenating strings. For the date/time parameter, set the parameter type to date/time, and pass Date.Now rather than Date.Now.ToShortDateString().

Here's an example:

public class Program
{
    static void Main(string[] args)
    {
        OleDbConnection conn = 
           new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=[put path to mdb here...]");

        conn.Open();

        OleDbCommand cmd = new OleDbCommand(
            "update Table1 set dateField = ? where textField like ?", 
            conn);
        cmd.Parameters.Add("@dateField", OleDbType.Date).Value = DateTime.Now;

        // IN THIS EXAMPLE, THE RECORD BEING UPDATED WILL HAVE "TEST"
        // IN THE FIELD NAMED: TEXTFIELD 
        cmd.Parameters.Add("@textField", OleDbType.VarChar).Value = "test";
        cmd.ExecuteNonQuery();

        conn.Close();

        Console.WriteLine();
        Console.WriteLine("Press enter to exit.");
        Console.ReadLine();
    }
}

When you open the MDB file you can confirm that the field has been changed to DateTime.Now.

code4life
A: 

The date format in Access is set by the locale in Windows, look at Control Panel, Region and Language Settings, unless you wish to set the format for individual fields via the format property of fields (columns) and controls.

When updating via forms and the query design window, you have some latitude, and in this case you are lucky that 18 is not a month, so most formats are unambiguous, however, in VBA and, I suspect, in c#, you should use either American date format (month, day, year) or an unamibiguous format such as year, month, day. i would generally prefer year, month, day over US dates, because they are clearer to more people.

Remou
Er, Access is not in use here, so the interaction between Access and the Windows Regional Settings is pretty much irrelevant. All that really matters is how C# handles date representations, and then you choose formats for presentation layer appropriate for your end users. If C# has default date formatting like VBA in Access, then when writing SQL, as you say, you have to be sure you use US date format or an unambiguous date form, as you say.
David-W-Fenton
@David-W-Fenton Er, read the post "when i open the Data Base i see that the value that was insert is "09/18/2010""
Remou
A: 

Always pass dates in explicitly mentioning month part in long format. For example for 01/24/2010 pass it as 24/jan/2010. In this case MS access will not get confused about month part and will process the date successfully. Later, date displayed will be as expected by you. Please remember that is applies for data insertion, updating and date fetches also.It will work for all Cultures because MS Access need not to worry about which part is month part of date value passed

PradeepGB
This is wrong. Access is not "poor in managing date values passed." It is, in fact, quite flexible with how it interprets string representations of dates and converts them to actual date/time values. But because of that flexibility, you have to be sure you're using the right string representations to insure you get the expected results.
David-W-Fenton
May be true. But the suggestion I have given always works under any culture. It is always a good idea to specify month part so that MS Access understands it correctly.
PradeepGB