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 @0700.
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

you said you wanted to set this up like people think.. who thinks like that?
(g)

how about simply using date / time ???

--
Steven Green - Myrtle Beach, South Carolina USA

Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales

Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Sports Memorabilia and Trading Cards

"Craig" <craig.futterman (AT) nospam (DOT) comcast.net> wrote

Steven,
Thanks for your reply.

Hospital people think like that. The day starts at 7 AM!

I had thought of doing DateTime, which will work. Since they won't be
entering the DateTime themselves, I'll have the computer populate the table
with all the Date/Times.

I was looking for any out of the box thinking.

Again,
Thanks,

Craig

"Steven Green" <greens (AT) diamondsg (DOT) com> wrote

Craig wrote:

Time of day is just an expression of elapsed time past an arbitrary start.
Instead of actual time of day, store the time as an integer offset from the
start of your workday in units to whatever granularity you need - minutes,
seconds, etc.

For minute granularity, you'd have 0700=0, 0715=15, 0730=30,...,0900=120,
0915=135,...,0600=1380, 0630=1395, 0659=1439

The same way of thinking works without an offset. 0700=420,
0715=435,...,0600=1740, 0659=1759


You have to translate this in and out during data entry, reporting, etc.
The simple way is to establish these values (using whichever scale you want)
as the PK in a lookup, then associate with the actual time of day. Then
rendering in a UI is a simple join or a backtrack.

I've used this approach several times, mostly regarding a broadcast
schedule, where the broadcast day starts and ends after midnight. Before
long it becomes automatic, and you start thinking in terms of offsets
instead of TOD.

--
Larry DiGiovanni

Thanks Larry,
I will have to think about this and try to put it into action.
Craig
"Larry DiGiovanni" <nospam@nospam> wrote

Larry and Steven,
Thanks for you replies.

I took a hybrid approach. (not a Prius) It seems to work quite well.
See below.

Thanks for you help.

Craig

t =Time("07:00:00 AM")
i = 0
TC.edit()
;TC.insertRecord()
While True
For j from 0 to 23 ;// # of hours in a day
TC.insertAfterRecord()
TC.MRNumber = stMR
TC.DateOfOperation = d

If j = 17 then
i = i+1 ;// increments the day after MN
ENDIF
t2 = t + (3600000*j) ;// increments the time by 1 hour (3,600,000
seconds/hr)
dt = Datetime(Strval(t2) +", "+ StrVal(d+i))

TC.DayTime = dt
TC.postRecord()
If i = 4 and j =23 then
quitloop
ENDIF
ENDFOR
If i = 4 and j =23 then
quitloop
ENDIF

ENDWHILE

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 importantly, 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
relationships.

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:

Craig wrote:

I'm fairly sure there are actually 3600 seconds in an hour. :-)

I didn't follow your example -- looks like there are some pieces missing --
but hope it does what you need.

--
Larry DiGiovanni

But there are 36000000 milliseconds. :-)

Anders

Keyboard error, should be 3600000 milliseconds.

Anders