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