Field Names too long?

L

LMB

Hi Everybody,

I am using Access 2000.

Starting to draw out a new database and in the past I have had problems in
certain areas of the database seeing the whole field name. I can see this
may be a problem with the names I have below since they would all look the
same if cut off but I tried to make them short but descriptive. Perhaps
it's in the expression builder section and or other places...Anyway, are
there any suggestions?

Also, I notice that many of the same people answer in the different
newsgroups, queries, reports, etc...I usually post in here but have
occasionaly posted in one of the other groups in MS public access which
are all very helpful too. I won't cross post but what is the best way to
post?...
I was thinking getting started meant, new users
but maybe it's the place I should have come before I went to table design?
What is the meaning of "getting started"?

tblPtVentThpy
PtVentThpyID
VentThpyTypeID_fk
PtVentThpyStartDate
PtVentThpyEndDate
PtVentThpyStartTime
PtVentThpyEndTime
PtVentThpyOrderNum
PtVentThpyFreq
PtVentThpyOrderPhys
PtVentThpyOnProtocols?
PtVentThpyActive?

Thanks,
Linda
 
J

John Nurick

Hi Linda,

Field names: In most places they appear it's possible to widen a column
or window so you can see the whole thing.

Unless you're working on a project controlled by someone else, naming
conventions are largely a matter of personal preference. For myself, I
don't normally incorporate the table name into the field names: I feel
it makes them harder to read (because the significant part is at the
end), and it's unnecessary because one can always disambiguate with the
TableName.FieldName
notation. So I'd probably have used something like
tblPtVentThpy
ID (is this field needed?)
TherapyTypeID
StartDate
EndDate
StartTime (is this truly independent of
StartDate or should is be incorporated into
a single StartDateTime field?)
EndTime (ditto)
OrderNumber
Frequency
OrderPhysxxx
OnProtocols (don't use special characters in field
names: sooner or later they'll confuse either you
or Access)
Active
 
J

John Nurick

I was thinking getting started meant, new users
but maybe it's the place I should have come before I went to table design?
What is the meaning of "getting started"?

The Getting Started newsgroup is for new users.
 
B

BruceM

Multi-posting is different from cross-posting, and is quite acceptable when
necessary. Multi-posting just means that you are posting the same message
simultaneously to several different groups. It is not often necessary, but
at times it may be unclear whether a question about a report's record source
is a report question or a query question. When you multi-post, an answer in
one group also appears the other.
As for when to use Getting Started, if you have a form question, first try a
groups search (Google groups works well), then try reading some of the posts
in the forms group. If you can follow some of the discussions that you
wouldn't have understood when you were new to Access, it's probably time to
post in the forms group. If you are familiar with forms but unfamiliar with
tabbed forms, the Getting Started group would probably be OK. There are no
hard and fast rules. Whether you are a beginner or not depends partly on
your own perception. I knew somebody who had taken a one-day Access course
and said "Oh, yeah, I know how to use Access", but didn't know about
relationships, yet still considers herself fairly advanced.
 
L

LMB

Thanks Bruce,

I am not new to Access, have taken many 1 day classes and have been given a
lot of help in these groups but I still think I am a beginner since I only
do it occasionally and not every day. I need to start dedicating time to do
a little every day now.

Thanks,
Linda
 
L

LMB

Thanks, John. StartDate and StartTime would work. I just make the
properties set to General, right? This looks strange to me and I do want to
calculate days and hours therapy lasted, filter records by date and have a
calculated field that gives an expiration date to certain therapy 5 days
after it's start time. How will this workout? It seems like it will be
hard for the users to get used to as they now have a seperate date and time
field. Are there any reasons not to keep them combined?

Linda
 
J

John Vinson

Thanks, John. StartDate and StartTime would work. I just make the
properties set to General, right? This looks strange to me and I do want to
calculate days and hours therapy lasted, filter records by date and have a
calculated field that gives an expiration date to certain therapy 5 days
after it's start time. How will this workout?

Provided you do the calculations correctly, just fine. Access does NOT
care what the Format of the date/time field is - what's stored is just
a Double Float number, a count of days and fractions of a day (times)
since midnight, December 30, 1899. You can have the same value
formatted a dozen different ways on different forms or reports, if you
wish; the DateDiff() and DateAdd() functions, and date criteria, will
work the same regardless of the format.
It seems like it will be
hard for the users to get used to as they now have a seperate date and time
field. Are there any reasons not to keep them combined?

I can't think of any really good ones. A bare Time value is equivalent
to a time on December 30, 1899 - and for searching and sorting
purposes, therefore it's usually recombined with a date anyway.

If the users prefer to see the date and time in two separate textboxes
on a Report, give them two textboxes, one formatted with a date only
format (mm/dd/yyyy for instance), the other with a time only format
like hh:nn. If they want to enter date and time separately you'll need
two unbound textboxes and a little bit of VBA code to split apart the
date and time (in the form's Current event) and put them back together
(in BeforeUpdate).

John W. Vinson[MVP]
 
J

John Nurick

If you store date and time (i.e. a point in time) as a value in one
field, the arithmetic for elapsed times and so on tends to be simpler,
especially if start and finish are on different days.

For a calculated field showing a date (but not time) five days after the
start date/time:
DateValue(DateAdd("D", 5, StartDateTime))

But if you've got it working satisfactorily with separate fields for
date and time, and the users are accustomed to it, there doesn't seem
any pressing reason to change things.

Thanks, John. StartDate and StartTime would work. I just make the
properties set to General, right? This looks strange to me and I do want to
calculate days and hours therapy lasted, filter records by date and have a
calculated field that gives an expiration date to certain therapy 5 days
after it's start time. How will this workout? It seems like it will be
hard for the users to get used to as they now have a seperate date and time
field. Are there any reasons not to keep them combined?

Linda
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top