If you really mean KEY when you say it you are using WAY TOO MANY key
fields. Move to meaningless integer keys. They will also help in the
sense that, unless data is not input sequentially they will help order
your data when you need it as well. They will, more im****tantly, vastly
simplify your links and the management of your tables. See my
normalization paper at our paradox resources page (link in my signature)
for more on how to use meaningless integer keys and key/foreign key
relation****ps.
Larry's point about the offset is also a good point for getting the
order and day correct but you still should simplify the structure.
Denn Santoro
President
Resource Development Associates
http://www.RDAWorldWide.Com
Offices in the United States and Germany
Providing solutions to health care, business, governments and
non-profits since 1982
Craig wrote:
> I am setting up some tables for data collection for a clincial study we
are
> conducting in our PICU.
> The set up:
> One of the data elements we are collecting is a sedation score. The
problem
> in hospitals is that the day starts @[EMAIL PROTECTED]
> The key fields which attach this daughter table to the master are
MRNumber
> and DateOfOperation.
> In this table I not only have that I have two other keys dayNumber (we
are
> collecting data for a max of 5 days) and timeofDay (we are collecting
data
> each hour). Of course, the last field is a non- keyed field called
"Score".
>
> The problem: All hospital personell work (& think) as the beginning of
day 1
> starts at 0700 and the last hour of day 1 is the next morning at 0600.
Since
> the data entry will be done by people who are not facile with computers,
I
> want the software to work like they think.
> If I setup the key fields as above, Paradox will automatically reorder
so
> that midnight 0000 through 0600 will come before 0700 through 2300.
>
> I was thinking about adding the hour # to the hour such as 1-0700,
2-800,
> 3-0900 though 24-0600 as a string for that key field. What do you guru's
> think?
>
> Thanks in advance,
>
> Craig
>
>
|
