What variable type do your F4 & lp functions return?
In your results file, jump to the bottom of the list. There are 2 line where only one value printed out. Look at the last entry and 8 lines from the last entry. I'm guessing you get an error with those entries?
Insomnia is just a byproduct of, "It can't be done"
I suspect we're getting inaccurate information. Basically, the way I read the OP (and the thread title), is that the following line is generating an overflow error:
Code:
diff_Calc = FormatNumber(v2 / v1, 1)
I thought about it, and also played around with it, and I just don't see how that's possible, especially with v1 and v2 being Long type.
Sure, it's easy to get a Divide-By-Zero, but an Overflow? If it were multiplication, an overflow would be easy, but not with division.
Sure, the results are a floating-point (or, more specifically, a Double). But a Double can handle anything that Long division can throw at it.
Code:
Debug.Print TypeName(1&/2&) ' Reports "Double".
IMHO, we're not being told the correct code line that the error is reporting on.
Maybe I'm getting hung up where jpatierno says "Trying to divide these 2 figs". If the error is occurring down in either the F4_Calc function or the Lp_Calc function, then that's an entirely different story.
Also, jpatierno, you say that "Pretty sure it has something to do with Dim'ing the varaibles (sic) v1 and v2". I just really don't see how that's the case. Dim (declaration) statements (for a Long) are doing nothing more than setting up a four-byte area, creating pointers to those areas, and also letting any VB6 operations know that those four-bytes are always to be treated as a 2's compliment Longs. Not really much more to it.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Didn't expect that. When you get the error, both v1 and v2 are zero. 0 divided by 0 gives you that error.
You are going to need to step through some of your code and determine where in your f4/lp routines you are returning a value of zero. And if zeroes are valid, then you will want to test to ensure v1 <> 0 or v2 <> 0. If so, either your data is bad, your calculations are bad, or the result would be zero anyway.
Look at your various "... = gFieldMapping.GetFieldValue(...)" methods. If the returned value is Empty, then you will be returning zero. In the case where the error occurred, these lines returned Empty:
Ahhh, I played around with it and never thought to try 0&/0&. Apparently, that's the answer.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
there are occasions where either F4 or Lp could be zero. Not on error though. So what code can over come this problem
simple really
Code:
Private Function diff_Calc(ByRef r As clsRecord, ByVal detailRecordNum As Integer) As Variant
Dim v1 As Long
Dim v2 As Long
v1 = Val(F4_Calc(r, detailRecordNum))
If v1 = 0 Then
diff_Calc = 0
Else
v2 = Val(Lp_Calc(r, detailRecordNum))
If v2 = 0 Then
diff_Calc = 0
Else
diff_Calc = FormatNumber(v2 / v1, 1)
End If
End If
End Function
Insomnia is just a byproduct of, "It can't be done"
Interesting, the overflow error message is a bit of a red herring it seems. I would not expect to see that error message when dealing with 0s. I would expect to see division by 0 but not the first time I have saw miss leading error messages.
I once had an error in a large program written by others that I had to track down. The error was "Statement to complex to process" The line that threw the error was RS.MoveLast or maybe it was RS.MoveFirst. [been a long time now] Anyway that had me scratching my head for a little while. Turned out the problem was that whoever designed the db used a text field for the qty and allowed it to be null. The query did some operation related to this field and the nulls caused a problem. Oddly the open rs worked without throwing an error but the move method took down the system and of course whoever coded it did not have an error trap in there so it crashed to the desktop. The odd error message had me looking in the wrong place for a bit but I managed to locate the issue and correct it Initially just by running an update query and setting all null qty to 0, Later I modified the db to use a numeric field and 0 default.