A zero-length string ("") contains no characters
but "looks like" a NULL. You see posts all the
time here where someone is filtering for Null on
some field but not getting all expected records
from the query results because some (or all) of
the "blanks" are not really Nulls.
.
I might shy away from setting AllowZeroLength
to Yes for that reason. But spaces "look like"
a Null also. In a perfect world, I would set
AZL = No
Req = Yes
*** mostly quote from Access Help ****
The Required (Req) property determines only
whether a Null value is valid for the field.
If the AllowZeroLength (AZL) property is set to Yes,
a zero-length string (ZLS) will be a valid value
for the field regardless of the setting of the
Required property.
AZL Req User's action Value stored
No No Presses ENTER Null
Presses SPACEBAR Null
Enters ZLS (not allowed)
Yes No Presses ENTER Null
Presses SPACEBAR Null
Enters ZLS ZLS
No Yes Presses ENTER (not allowed)
Presses SPACEBAR (not allowed)
Enters ZLS (not allowed)
Yes Yes Presses ENTER (not allowed)
Presses SPACEBAR ZLS
Enters ZLS ZLS
*** unquote ***
But it's not a perfect world....
Your business and what you intend to do with
the data drives data design...
In one of our apps at work we keep track of
special orders for books. Our "business" says
we want to be able to contact a customer when
a book comes in. We don't allow a record to be
saved unless it has at least a phone number and address
for the customer.
You can also "make contact" via email address or fax
but not everyone may be able to (or want to) provide those.
I know I give out as little personal info as I can to complete
a transaction nowadays.
Our users are trained in what fields are required or not.
And for those "not" fields, I set AZL=Yes / Req = No
This eliminates confusion when a record won't save
because some irrelevant field has a "blank." Note
in table above that is the only setting w/o "(not allowed)."
Go ahead, enter whatever you want (or don't enter anything),
we don't care what your devilish minds can think up to
throw a wrench in the works, just serve the customer
as quickly as you can...
We complete this data while communicating with the
customer. It sounds like your situation is different, i.e.,
your card scanner will provide only what is available
on a card. You don't want what info it does provide
to not be "enterable" just because the card did not
provide a fax number I imagine.
Some data aquisition software (possibly like your
card scanner) like to provide a ZLS in a field rather
than Null.
Your purpose for and means of gathering the data
will determine what is required/allowed. My guess
is that for the "don't-care" fields in your tblContacts,
you want
AZL = No
Req = No
(allowing Null's but not ZLS)
and use "method 2" when you import from card table
where any "blank" is changed to "N/A."
But
AZL = Yes
Req = No
will only require you to remember to use
WHERE Len(Field) > 0
instead of
WHERE Field IS NOT NULL
in filter query for "non-blanks"
You know your data best....
Gary, before I say thanks again...
What is the advantage and or disadvantage of doing this;
[quoted text clipped - 52 lines]