Not sure what is actually in the "text" field.  And not sure what you will do with results, but a few approaches come to mind.

1.  Make a new field TempNumb, type = N6
Run Mass Update so TempNumb=ExistingTextField

Now all former numbers will be numbers, all former text values will be empty. leading zeros will be gone.

Now can delete oldfield and rename new field to oldfieldname

---------------------------------------------
2.  Check for characters NOT 0-9 in the string of the field.   Ascii Codes for 0-9 are 48 thru 57.    These will be text fields.

May have a problem with periods?  What about data that has letters plus numbers?  Would have to get length of each string, and loop for ascii values for each character in the string.......too much programming.

----------------------------------------------
3.  Retrieve records with the following UNTESTED formula in the FieldName:

{IF @InStr(FieldName,0)>0}
OR
{IF @InStr(FieldName,1)>0}
OR
{IF @InStr(FieldName,2)>0}
OR
...
...
...
{IF @InStr(FieldName,9)>0}

This will ID all records that have no numbers in them.
Mass Update these records putting a flag in a temp field, then retrieve all records that are not flagged.  This result set should be all records that do have numbers in them.

Syntax may not be totally correct, have not tested, but I hope you get the idea.  If there is no 0-9 anywhere in the string, then this must be pure text.
----------------------------------------------------

I think option 1 may be the easiest.  After the MassUpdate you will have both fields available to compare results before you delete/replace the original values.....

There's an easy way. To be safe do this on a copy of your database.
In Q&A, change the field from text to number. Then search in the field:

 /..

That is forward slash period period. This searches for non-valid entries.

Looks good to me.  Make sure all the fields are Number fields.

I just did this without looking at yours, and came up with the same formula.  This works for me in the field for #4:
{ #4 <> (#1 + #2 + #3)}

But technically that formula could go into any other field, does not need to be in #4.  In fact, I just tested that by putting the formula in a text field, vs. the #4 number field.

Further:  It looks like the 291 records returned by the "addition" calculation are also present in the set of 1813 returned by the "subtraction" calculation.

THINGS SHO' DO BE GOIN' CRAZY 'ROUND HEAH!

The + operator should be the one which returns the incorrect invoices, where the calculation does not match the Invoice Total.  However, all the records retreived do match.  That is, the invoice are correct.

I've decided to try this using a report, with Derived Colums and a True/False comparison.  I'll let you know how it goes.

I've made a report.  The structure is:

Retreive spec: blank (all records)

Sort spec:
Col.1: Invoice Number
Col.2: Subtotal
Col.3: Discount
Col.4: Additional Charges
Col.5: Invoice Total

Derived Columns:
Derived Col. 6: #2+#3+#4 (calculated total)
Derived Col. 7,AS: #5=#6 (test)

This report runs on ALL my invoices and prints to screen.  Smack dab at the top of my screen it shows me that I have one (1) Invoice where the total of the three fields do not match the Invoice Total.  The remaining 30,061 records return "True" to the test field.

YAY!  I have my answer, and it's an easy fix.

However, I am still baffled by the earlier searches.  For the sake of closure I would love it if someone could explain why they failed.  Q&A must have some sort of problem performing this math in a retreive.  Is it due to them being money fields?  The exisitence of a negative number?  Gremlins in the machine?  Am I just having a bad month?

Yes, thank you Ray, rounding is precisely the problem.  The discount amount is based on a percentage given to the customer.

Whew!  I'm glad that's solved!  Thanks Ray, Erika and Bob!  This forum is great!