Post by Robert BraveryMervyn,
I believe youre wrong here. If youre talking about the date data type.
But if your talking about a nornaml char data type. well then thats
different. But I believe the thread is about date data type.
If you want to be specific, data as a data type is NOT stored as
character. But as bytes. Infact all data is stored as bytes. As far as I
know you cannot store a blank byte. It has to represent a byte. My
answer was simplistic, but enough to answer the question.
Most places that I read, all say the same, and that is that dates are
stored as byte intergers, and not characters. When last did you store a
Blank Interger. It is either null or a int value.
"Date variables are stored as IEEE 64-bit (8-byte) integers that
represent dates ranging from January 1 of the year 1 through December 31
of the year 9999, and times from 0:00:00 (midnight) through 11:59:59 PM"
It seems that you CANNOT store a blank interger, by nature of the
datatype. By nature there is always something stored, either a null
value, which is in question here, or an interger value. For Date data
type this is a value of 0-2958465. Which gives you a date value of
between 1900/01/00 and 9999/12/31. But strictly speaking 1900/01/00 is
not a valid date. So the actual valid interger value is 1-2958465. -1
gives an error, as does 2958466. It is not spaces or blanks. It is
either a Null or an interger value, infact it is an 8 byte value.
Firstly, the first 6 words of my previous post were "A date is stored on
disk" and the second paragraph started with "When dBase reads a date from
disk it converts the 8 characters into a number internally." That
internal number could well be your IEEE 64-bit number. It was not, and
still isn't, important to the point I was making.
I was technically incorrect when I said data was stored as characters. As
you have pointed out that should have been bytes. Fair enough but for
today's date those 8 bytes would have the hex values of 32 30 30 38 31 30
32 33 which represent the ANSI values for 2 0 0 8 1 0 2 3 and this is true
whether dBase and/or regional settings dictate that the date be displayed
as 10/23/2008 or 23/10/2008 or 23-10-2008 or whatever.
You don't believe me? Fine but go and conduct your own little experiment
and then we can talk again. Create a table with a date field and, for
good measure, a numeric field. Append a blank. Replace the date with
date() and the the numeric field with a value such as 12345.67. Append a
blank Append a blank and replace the date and numeric fields as above.
(This is to establish a pattern so that you can easily see where the
records are and what is in them without having to delve too deeply into
the structure of a .dbf table or having to bother with counting bytes.)
Close the table and open it in a hex editor.
The unused date field will have 8 bytes of hex 20 which is the ANSI code
for "space". The unused numeric field will be filled with hex 00 which is
the ANSI code for null. If a numeric field is ever used and then cleard
by storing zero to it, the field on disk will be filled with hex 30 which
is the ANSI code for 0. dBase can, therefore, distinguish between null
and empty for a numeric field. dBase cannot distinguish between null and
empty for a date field as it starts out on disk with empty values, not
null values.
A timestamp field is, however, quite a different story. This is stored on
disk as 8 bytes that represent a 64-bit number. It starts out as 8 bytes
of null so dBase would be in a position to determine if it is null or
empty. But then again this thread started out discusing date fields, not
timestamp fields.
Mervyn.
This brings me back to my original contention. A date field, on disk,
starts out filled with spaces, not nulls. dBase is, therefore, unable to
determine if a date field has