[AccessD] Presenting data problem

Ah! 

There's another table, set of queries and forms:
Earliest date
latest date
Scheduled date
actual date
(reason for delay if actual not as schedules)
Vet'nry action (required) - keyword as in vaccine- name, rather than "Injection"
Consumable(s)  freeform
Estimated time required 
Estimated cost
Follow-on action to be scheduled (or check bookings)
Completed by (organisation)
Completed by (person/vets name)
Witnessed by (Staff member)
Invoice reference

Queries to show (print) 
Tomorrows/today's/a date's events
Staffing needs 
Outstanding within future period
Missed events

-------------------------
I suspect that, when you have got it working there may be a market for the
facility -
Reasonable charge - and licenced for use - as is, support to be under separate
agreement(s).
It may not bring in much per licence, but lots of licences could defray a lot of
the development costs, and maybe even get you a small profit.

That's basically how some of my ongoing income came about.
Once the package gets out 'there' word of mouth can work wonders, especially if
there is a tablet interface for entering and viewing data so it can be shown off
when in the field, or visiting like establishments. 

JimB 



-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
Sent: Wednesday, October 29, 2014 10:51 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Presenting data problem

Well, the boss is simplifying things a great deal. All she really wants is
to track vaccines and vet visits. For vaccines, I'll need to know what
vaccines are expected and track when they're due and when they're applied.
For the vet visits, just date, comment, and the ability to scan lab
results. Getting all those vaccines by species will be the hard work -- but
the structure for it won't be so bad.

Susan H.


>
> Based on that experience, my only comment would be to trend towards
> discrete
> tables as much as possible in your design.  While the EAV design has its
> uses, it has short comings as well.
>
> Arthur's setup is a good in that your still using tables more or less, it's
> just that you have multiple tables stored together and in doing that, save
> yourself some work.  But really without much extra effort, you probably
> could bust a lot of that out into separate tables.
>
> I might also suggest that to cover the "loose ends", consider adding a
> diary/comment system (ie. "Lab notes") with a keyword search on it.   It's
> not typically something I like to do in a design because users start
> putting
> everything and anything in there and it's all free-form, but sometimes it
> is
> one way to get the job done.
>
>
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com