[AccessD] Presenting data problem

Arthur,

Nice, and the addition of a new set will become almost rote,
 and for those with (or that grow to have) lots of entries
 it should be easy to split the details into multiple rows that hold a form's or screen's worth of aspects/data 

Wish I had thought to setup that for some of the inventory stuff I had to do a long while ago.

As in did the software come as an upgrade to a hardware add-on that was gifted under special terms from another department, and can only be used in association with another bit of hardware ... and consequently is not subject to annual depreciation, and thus taxation write-off etc.

Susan, 
I'm not sure that it is appropriate to start off the thread using the word 'Simple' ?
Convoluted or perhaps tortuous seem to be more appropriate the way you are going with this. 
But I hope you are enjoying the experience. 


JimB

-----Original Message-----
From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Tuesday, October 28, 2014 6:27 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Presenting data problem

Susan,

Some years back, I wrote had a vaguely similar app; well, similar in the
sense that my SalesDetails table has to store a variety of different
"objects": event tickets, hotel bookings, limo bookings (to and from the
airport), perhaps car rental, and a few others. My first thought was to
have several types of SalesDetails tables, each corresponding to a
different type of object. But the downstream problem of creating an
itinerary for the whole package, based on date/time of the item, proved
insurmountable. So finally I opted for creating a single SalesDetails table
containing all the columns necessary to support all the DetailTypes, and
adding a couple of columns for DetailType and Description. A separate
table, DetailTypes, contained a list of Detail Types and a column
containing the name of the form to load. The record source for each detail
form was a named query (as time went on and the app moved from Access to
SQL Server, the named queries became Views) that presented only the fields
relevant to that particular detail type. Each of these forms contained an
identically named procedure called MakeDescription, that assembled the
values into a readable text string. For example, in the case of a flight,
it would say something like "Business class tickets, Air Canada Flight 123,
departing at 12:30 p.m, arriving at 2:00 p.m". The quantity, price and
amount columns contained those values.

Yes, the model broke some normalization rules, But there were two
significant gains in this approach. First, printing the itinerary was a
cinch, since all the details were in a single table. Second, as the firm
expanded its range of offerings, I had to make almost no code changes: just
design a new detail form, add a row to the DetailTypes table, and write a
new MakeDescription procedure to assemble the text string for Description.

You might consider this approach in your animal app. The named queries hide
all the columns irrelevant to the particular disposition type, while still
allowing you to view/present them in a single subform.

Arthur
​
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com