At my company, we have recently gotten somebody to update our in house program written in Foxpro. We got VFP 5.0 and created a window environment. The person who did the code wrote it in I believe SQL Exec code. The problem we are having is that sometimes when the program writes to the file, it will round the data to the nearest dollar while still showing on the screen properly. It doesn't do it everytime, but enough times to be frustrating. Any ideas or suggestions would be greatly appreciated.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Rounding problems with my program 1
- Thread starter dawg
- Start date
Without specifics, it's hard to say where your problem might be. However, there are a few things you can look for:<br>
<br>
1) If the program is creating a table on the fly (which is different than formatting results for screen output) and the first calculation happens to be 10 x 95, VFP sees the result as 950 and the resulting field will be created with 0 decimals. Regardless of whether subsequent calculations have more decimals, they will be rounded up. If instead, the calculation was 10.00 x 95, the result will be 950.00, and the field will have 2 decimal places. You can prove this to yourself by doing this calculation in the command window. If you are entering data on-screen, the program may be written in such a way that the operator has to enter 10.00 and not 10 to get the desired result. A little additional programming should take care of that.<br>
<br>
2) Make sure the file structures have sufficient decimal places specified for the results you need.<br>
<br>
3) Depending on where in the chain of events the calculations are taking place and the results are being written to a file, rounding can occur. Check through the program logic to step through the series of calculations one at a time.<br>
<br>
I hope I've given you some ideas of where to start looking.
<br>
1) If the program is creating a table on the fly (which is different than formatting results for screen output) and the first calculation happens to be 10 x 95, VFP sees the result as 950 and the resulting field will be created with 0 decimals. Regardless of whether subsequent calculations have more decimals, they will be rounded up. If instead, the calculation was 10.00 x 95, the result will be 950.00, and the field will have 2 decimal places. You can prove this to yourself by doing this calculation in the command window. If you are entering data on-screen, the program may be written in such a way that the operator has to enter 10.00 and not 10 to get the desired result. A little additional programming should take care of that.<br>
<br>
2) Make sure the file structures have sufficient decimal places specified for the results you need.<br>
<br>
3) Depending on where in the chain of events the calculations are taking place and the results are being written to a file, rounding can occur. Check through the program logic to step through the series of calculations one at a time.<br>
<br>
I hope I've given you some ideas of where to start looking.
-
1
- #3
One more thing to check, though if it works *some* of the time but not others, this may not be it:<br>
<br>
If there are occurences of STR() that do not include the third parameter (decimal points), and the result is used for reports, etc, it would appear rounded in some circumstances.<br>
<br>
If there are occurences of STR() that do not include the third parameter (decimal points), and the result is used for reports, etc, it would appear rounded in some circumstances.<br>
- Status
Similar threads
