D
DaJynx
I am looking for a way to see the stored values in Access.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
R
Rick B
You want to see the data in your database? You would do that with a query,
report, or form. This question is way to vague. What are you specifically
trying to accomplish?
report, or form. This question is way to vague. What are you specifically
trying to accomplish?
D
DaJynx
I want to know how Access stores the Date/Time data type. I know that the
field will store 8 bytes. If I input 1/1/2003, how is it stored in Access?
Thank you for your response.
field will store 8 bytes. If I input 1/1/2003, how is it stored in Access?
Thank you for your response.
R
Rick B
Here is a previous post that I think will answer your question...
--
Rick B
A JET date/time field always stores both a date and a time, although Access
may not display them. The value is stored as a Double, with the part before
the decimal point indicating the number of days since 30 December, 1899, and
the part after the decimal point indicating the time as a fraction of a day,
e.g. .5 is noon, .25 is 6AM, .75 is 6PM. Either part may be 0, but that does
not indicate the absence of a date or of a time, 0 is a valid date (30
December 1899) and .0 is a valid time (midnight). You can not distinguish
between 'different types of date/time fields' by looking at the schema of
the table, because there are no different types.
If you want to prove this for yourself, try creating a table with two
date/time fields. Set the format for one field to long date, and for the
other to long time. Enter a few test values. Enter a time with no date in
the field with the long date format, and a date with no time in the field
with the long time format, ignoring the way they are displayed for now. Now
go into design view and swap the formats around - give the field that has
the long date format the long time format, and the field that has the long
time format the long date format. Go back into datasheet view and look at
the values you previously entered.
Even if your code were to look at the actual values in the table, to be
completely sure, you would need to look at every record. It would not be
safe to just look at the first record, find that the date was 0 (30
December, 1899) and assume that therefore the field was being used only to
record times - just because no date part was explicitly entered in the first
record does not mean that no date part was explicitly entered in subsequent
records.
What is the problem you're trying to solve here? If we knew what the problem
was, perhaps we could suggest an alternative solution?
--
Brendan Reynolds (MVP)
[email protected]
--
Rick B
A JET date/time field always stores both a date and a time, although Access
may not display them. The value is stored as a Double, with the part before
the decimal point indicating the number of days since 30 December, 1899, and
the part after the decimal point indicating the time as a fraction of a day,
e.g. .5 is noon, .25 is 6AM, .75 is 6PM. Either part may be 0, but that does
not indicate the absence of a date or of a time, 0 is a valid date (30
December 1899) and .0 is a valid time (midnight). You can not distinguish
between 'different types of date/time fields' by looking at the schema of
the table, because there are no different types.
If you want to prove this for yourself, try creating a table with two
date/time fields. Set the format for one field to long date, and for the
other to long time. Enter a few test values. Enter a time with no date in
the field with the long date format, and a date with no time in the field
with the long time format, ignoring the way they are displayed for now. Now
go into design view and swap the formats around - give the field that has
the long date format the long time format, and the field that has the long
time format the long date format. Go back into datasheet view and look at
the values you previously entered.
Even if your code were to look at the actual values in the table, to be
completely sure, you would need to look at every record. It would not be
safe to just look at the first record, find that the date was 0 (30
December, 1899) and assume that therefore the field was being used only to
record times - just because no date part was explicitly entered in the first
record does not mean that no date part was explicitly entered in subsequent
records.
What is the problem you're trying to solve here? If we knew what the problem
was, perhaps we could suggest an alternative solution?
--
Brendan Reynolds (MVP)
[email protected]