I wonder if there is a way to detect that a numeric field in a record is filled with ******** as a result of a numeric overflow in a calculation
Please enlighten me
Rafael Copquin
--- Este correo electrónico ha sido comprobado en busca de virus por AVG. http://www.avg.com
You could do a little function that:
IsOverflow(tnVal) LOCAL cVal, lStat m.cVal = STR(m.tnVal) IF m.cVal="*" m.lStat = .t. ENDIF RETURN m.lStat
Fred
On Fri, Jul 7, 2017 at 10:22 AM, Rafael Copquin rafael.copquin@gmail.com wrote:
I wonder if there is a way to detect that a numeric field in a record is filled with ******** as a result of a numeric overflow in a calculation
Please enlighten me
Rafael Copquin
Este correo electrónico ha sido comprobado en busca de virus por AVG. http://www.avg.com
[excessive quoting removed by server]
Forgot "FUNCTION" in front of "IsOverflow(tnVal)..
Fred
On Fri, Jul 7, 2017 at 10:31 AM, Fred Taylor fbtaylor@gmail.com wrote:
You could do a little function that:
IsOverflow(tnVal) LOCAL cVal, lStat m.cVal = STR(m.tnVal) IF m.cVal="*" m.lStat = .t. ENDIF RETURN m.lStat
Fred
On Fri, Jul 7, 2017 at 10:22 AM, Rafael Copquin rafael.copquin@gmail.com wrote:
I wonder if there is a way to detect that a numeric field in a record is filled with ******** as a result of a numeric overflow in a calculation
Please enlighten me
Rafael Copquin
Este correo electrónico ha sido comprobado en busca de virus por AVG. http://www.avg.com
[excessive quoting removed by server]
Pretty smart! Thank you Rafael
El 07/07/2017 a las 14:44, Fred Taylor escribió:
IsOverflow(tnVal)
LOCAL cVal, lStat m.cVal = STR(m.tnVal) IF m.cVal="*" m.lStat = .t. ENDIF RETURN m.lStat
--- Este correo electrónico ha sido comprobado en busca de virus por AVG. http://www.avg.com
I sometimes run into this with variables and/or fields. In either case, you can pre-test a value and/or format using the transform() function as well.
If TRANSFORM(a,"@L 999.99") = "***.**" Endif
The nice thing about this method is you can control exactly the format of the value you are testing.
Alternate test:
If occurs('*',TRANSFORM(a,"@L 999.99") ) > 0 Endif
Paul H. Tarver Tarver Program Consultants, Inc. Email: paul@tpcqpc.com
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Rafael Copquin Sent: Friday, July 07, 2017 12:22 PM To: profoxtech@leafe.com Subject: numeric overflow
I wonder if there is a way to detect that a numeric field in a record is filled with ******** as a result of a numeric overflow in a calculation
Please enlighten me
Rafael Copquin
--- Este correo electrónico ha sido comprobado en busca de virus por AVG. http://www.avg.com
[excessive quoting removed by server]
Thank you Rafael Copquin
El 07/07/2017 a las 15:57, Paul H. Tarver escribió:
I sometimes run into this with variables and/or fields. In either case, you can pre-test a value and/or format using the transform() function as well.
If TRANSFORM(a,"@L 999.99") = "***.**" Endif
The nice thing about this method is you can control exactly the format of the value you are testing.
Alternate test:
If occurs('*',TRANSFORM(a,"@L 999.99") ) > 0 Endif
Paul H. Tarver Tarver Program Consultants, Inc. Email: paul@tpcqpc.com
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Rafael Copquin Sent: Friday, July 07, 2017 12:22 PM To: profoxtech@leafe.com Subject: numeric overflow
I wonder if there is a way to detect that a numeric field in a record is filled with ******** as a result of a numeric overflow in a calculation
Please enlighten me
Rafael Copquin
Este correo electrónico ha sido comprobado en busca de virus por AVG. http://www.avg.com
[excessive quoting removed by server]
Hi all
Have been looking at all the responses to this and thought it might be useful to point out another potential problem with values in numeric fields with a decimal part. If you have a field MyField N(6,2) in theory it should have a maximum value of 999.99. However VFP will happily store values like 9999.9, up to 999999. IMO VFP should not allow this and it is a problem when accessing the data using ODBC or OLEDB. The solution for us was to disallow values greater than VAL("999.99"). The character part being constructed knowing the field definition, in this case N(6,2)
Paul Newton
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Rafael Copquin Sent: 07 July 2017 18:22 To: profoxtech@leafe.com Subject: numeric overflow
I wonder if there is a way to detect that a numeric field in a record is filled with ******** as a result of a numeric overflow in a calculation
Please enlighten me
Rafael Copquin
--- Este correo electrónico ha sido comprobado en busca de virus por AVG. http://www.avg.com
[excessive quoting removed by server]
On 7/11/2017 3:32 AM, Paul Newton wrote:
Hi all
Have been looking at all the responses to this and thought it might be useful to point out another potential problem with values in numeric fields with a decimal part. If you have a field MyField N(6,2) in theory it should have a maximum value of 999.99. However VFP will happily store values like 9999.9, up to 999999. IMO VFP should not allow this and it is a problem when accessing the data using ODBC or OLEDB. The solution for us was to disallow values greater than VAL("999.99"). The character part being constructed knowing the field definition, in this case N(6,2)
A side note: you can use database triggers to restrict values stored in databases.
And for VFP "screens" you can use the spinner control to get good control of value ranges. Actually, in VFP, you could create a subclass control that would examine the underlying data structure type and limit things in its own valid event, blah blah blah (and it could be pretty generic and handle all kinds of rules with numbers).
But yes, since VFP stores its "N" format as a character representation of a number instead of a "true" number, these weird things happen.
-Charlie