Jim Carter wrote:
Drew -
I highly approve of the approach.
It has the merit of "Northwind" - i.e. more stuff than you will use,
but it works!
One of the things I am excited about is that the Professor Casanova is
not an database guy or IT consultant/trainer - he is a Therapist and he
chose therefore to base the database on what he actually knows.
Apparently a single user application can fit for a good number of these
professional Psycho-Therapy clinics. Even though there are multiple
staff members, one or two Psychiatrists - perhaps, a few licensed
Therapists and an Office Manager. This is the person that would be using
the database. She gets to do all the real work on the actual business
side of things and of course gets the smallest pay check - hey, what do
you know the OOo user is a she after all...( ok ladies - please throw
over ripe tomatoes only - no hard green ones )
Seriously though, he is trying to keep the scope of the example
manageable, but with enough to cover a good bit of ground. So the schema
has mostly 1..n relationships, but a n..n also, there is a minimal
account table for showing an actual transaction concept, but not going
to do trial balances, generate deposit slips or export to accounting
packages.
One question I have relates to the middle initial in a name. Is that
a part of the first name? Perhaps a separate field? Another is the
title used in correspondence -- another field? Minor points, but
normally included in a "working example". The more of these that are
taken care of in the example the easier it is to pick up and use
without creating a nightmare later.
Another question relates to addresses. Having converted some
databases in the past, I think there are some things that could be
done to standardize presentation of these in some way. Perhaps it is
overkill to try to deal with that in this database, but any sorting of
addresses starting with a street number in a text field will cause
interesting results. If the example were to make a case for using
numbers as a separate field it might be useful.
Yes, it needs to fill a couple of gaps for data items thanks.
Spelling errors in data entry fields can lead to surprises - but that
kind of quality control issue may be something that doesn't need to be
handled by entry masks or choice fields.
Well, my example might of been misleading - there are lookups in the
system, I was just thinking of not using a separate table for at least
one field.
The long field names will be more help than hindrance in many cases.
It will give you a very sparse spread sheet when the table is
presented that way. The length of the field name will produce wide
columns with limited data in the cells. If the reports are an
integral part of the example database this will produce some appealing
results presuming fields are clipped when displayed, since the name of
the field may be much longer than the data in the field, and the
formatting will change when real entries are used.
I tend to pretty much never drive reports from tables - queries and
views with aliases instead - so why not stick to the tried and true way
for the data entry forms also...jees I don't know - it was a thought - a
rapidly dimming one it seems....it seemed like an interesting idea at
3AM....la di da ....now that the gray morning light of winter is beaming
through the windows...well, maybe not so much.
Right now there are six reports specified. My plan for the moment is
five will be Report Builder generated and one Report Wizard generated.
This includes a hard copy schedule however and for that I might want to
go with a Calc sheet with a linked data range. Haven't decided yet - I
suppose it makes the most sense from the stand point of OOo features
covered.
Drew
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
