Time not calculating properly

[merlynsdad]

varSignon = 8:24:51AM, varSignoff = 6:29:14PM.
My code reads

If rst1![event_type] = 3 Then
varSignoff = rst1![signoff]
varSignon_Dur = ((varSignoff - varSignon) * 24 * 60 * 60)

Event_type=3, so varSignon_Dur should equal 36263 seconds, but is showing zero, but computes correctly prior to this. Any problems in this formula?

If the square peg won't fit in the round hole, sand off the corners.

 

[dhookom]

Is there a reason why you don't use DateDiff("s", varSignon, varSignoff)?
Where does varSingon come from? Is it possible any of these are null?

Duane
Hook'D on Access
MS Access MVP

 

[merlynsdad]

I tried DateDiff but got the same zero answer for varSignon_Dur. varSignon is initiated earlier in the module and when this code runs, has a value of 8:24:51 AM. After this code runs I null all the variables before the code loops to another day, but at this point none are null. I'm using the Watch Window (see earlier post on making the font bigger) to keep track of all the variables, and stepping through the code to see them change as expected. But the zero is an unexpected number; I should be getting 36263 seconds.

If the square peg won't fit in the round hole, sand off the corners.

 

[dhookom]

Throw in some breakpoints and debug.print to see what is going on.

Duane
Hook'D on Access
MS Access MVP

 

[merlynsdad]

It's going thru a loop, so it's the same code every iteration. 10 times through the loop; 7 times the code works, 3 times it doesn't. Even when I step it through, I see it fail, but it's a simple A=B-C formula, and there's no clue why it fails.

If the square peg won't fit in the round hole, sand off the corners.

 

[merlynsdad]

Is there any known issue with DateDiff when you're subtracting a time from 11:59:59 PM?

If the square peg won't fit in the round hole, sand off the corners.

 

[dhookom]

I'm still having trouble seeing any code or data. DateDiff() has always worked as expected for me.

Duane
Hook'D on Access
MS Access MVP

 

[merlynsdad]

FYI this code works off a call center phone database. I discovered that the phone database had thrown me a curve. It normally does A, B & C in order, but someone did something totally unexpected and caused it to do A, B, B & C, which threw off the code entering the loop. Thanks for your patience and insight.

If the square peg won't fit in the round hole, sand off the corners.

 

[missinglinq]

'Tis an old, old adage, but still true, nonetheless: GIGO

The Missinglinq

Richmond, Virginia

There's ALWAYS more than one way to skin a cat!