I could not see where you were going with your reply because I thought I had thought through all of what you said.

In my mind I could not get from '999.99' to 999.99. I was stuck on trying to do some sort of TRANSFORM() or VAL() combination but could not find a way to deal with the decimal.

Your suggestion for EVAL() is the key for that part. I use EVAL() all the time but did not see its usage here. Good idea thanks.

I have already thought through the use of AFIELDS() and have a function started for that to build the '999' string. I am really looking for something more concise to build the '999.99' string.


I know where and how to use resulting number in REPLACE FOR, SCAN FOR, SELECT etc. Thanks.



>Ron --
>
> Following your approach, the function AFIELDS() dumps the file structure of a table into an array. Cycle through, test for numerics, and create a string value with 9's for the entire width of the field. Then, if there are decimal places, place the decimal point to the right of that number of digits. Then, EVAL() that string to get a numeric value for the test.
>
> To process an entire table at a time, it might be worthwhile to create a string expression into a macro substituted variable which you can place in the WHERE clause of a SQL statement.
>
> Another approach, which is much simpler and almost as accurate, is to test for the marker VFP uses for numeric overflow.
>
>

>SELECT * ;
>    FROM MyTable ;
>    WHERE "*" $ TRANSFORM(MyField)
>

>
> The entire table still has to be processed, so the AFIELDS approach, and building a macro substituted string of all numerics would still be a time saver. In most cases, this will work. However, VFP will occasionally do some weird truncation of overflow values for 1 digit greater than the field size, without using the overflow marker.
>
> Jay
>
>>I have a table that has a numeric field in it (actually lots of tables with numeric fields).
>>
>>ActChge N(6, 2)
>>
>>Obviously the highest number that should be in this field is: 999.99
>>
>>I am trying to come up with a way to programmatically interrogate the field size of the table, build the largest possible number then use that in a validation routine. The data is old in these tables. I am moving Data to SQL Server and need a routine to check for invalid data in numeric fields.
>>
>>I am having a problem easily determining the # of decimal places in the field size as well as building the subsequent largest # with decimal places.
>>
>>I.E.
>>
>>nLargestPossiblNumber = GetLargestNumber('ActChg', 'table')
>>cField = 'Table.ActChg'
>>IF EVAL(cField) > nLargestPossibleNumber
>> ** I have a problem with the data
>>ENDIF