Calculating hours worked from DateTime stamps

[Hueby]

Hey all,

I'm putting together a simple "Time Clock" program. In the SQL database are stored different rows for clocking IN, OUT, etc. with a DateTime stamp.

In SQL you can use this code to find the hours:

set @Time1 = '12/18/2002 11:00 am'
set @Time2 = '12/18/2002 12:00 pm'

select cast(@Time2-@Time1 as float) * 24 = 1 hour

....now.... I want to do this calculation in Crystal Reports. So, I have the IN and OUT time shared as a dateTimeVar and am trying to do the calcuations like so:

shared DateTimeVar OUT;
shared DateTimeVar INa;

numbervar total;

total := (OUT - INa) * 24;

total;

...but... it is coming out to weird numbers that I'm not sure what is going on. Can anyone help with this some? or maybe suggest a better method here? Thanks

 

[smcnulty2000]

That ought to work, on the face of it. You should get 1 hour for either set.

Okay, so digging deeper: why are you sharing the variables?

Also: what do you mean by weird numbers? If you post them we might recognize them.

Scott

 

[lbass]

You should be able to use datediff(), depending upon your report structure, as in:

datediff("s",{table.datetime},next({table.datetime}))/86400

-LB

 

[Hueby]

Thanks for the reply everyone. I am sharing variables right now because some of my times (a Lunch clock out/in) come from a sub report.

these are the numbers I get...

11:25 am - 2:45 pm = 0 hours

8:32 am - 4:50 pm = 30.22 hours

1:32 pm - 4:32 pm = 3.31 hours

7:05 am - 5:00 = -86.54 hours

I'm currently playing with some different things, trying to get something to work... thanks

 

[Hueby]

am I hopeless here, anyone have some other suggestions or better methods?

 

[Hueby]

I got it working now, I added a seperate group for to put my calculations in and it works... weird!

 

[smcnulty2000]

The only thing I can think of is that something is screwed up with your subreport. The math you show should be straightforward, so something else has to be going on.

The subreport is the next likely culprit, of what you've discussed.

Maybe you should take the subreport out of the mix and test that way. Then if that doesn't change anything you can dig elsewhere.

scott.