give it less decimal places, and you can have higher numbers.
I don't understand what is so complicated. Rereading the SQL Server help decimal(38,20) means a total of 38 digits with 20 deimal places, which is overly precise for prices and goes up to quintillions.
SQL server does interpret decimal(x,y) a little different than VFP interprets N(x,y). With this knowlegde it's just a little bit of testing.
decimal(38,20) besides a little different storagte than numeric(38,20) means 38 places, 20 of them decimal places after the decimal point. VFP can only support 20 places in total, so if you want to support prices up to millions and with 2 decimal places, then it's N(11,2) for VFP, because VFP counts the decimal point as a place and reserves one for the sign, and in SQL Server you'll need numeric(9,2) or decimal(9,2).
You can stay with decimal(38,20) in SQL, but use CAST([Unit Price] As decimal(9,2)) As Unit_Price works for example, resulting in N(11,2) on the vFP side. decimal(12,5) works too and results in N(14,5).
Now just remember VFP can go up to maximum N(20,d) with d maximum 18 and you knwo what you can CAST or convert to in SQL Server, that can be transferred to VFP.
Code:
lnH=SQLStringConnect("DRIVER={SQL Server};SERVER=...;Trusted_Connection=YES;DATABASE=...")
SQLExec(lnH,"Select CAST([Unit Price] As decimal(9,2)) As Unit_Price From Prices","curTest")
SQLExec(lnH,"Select CAST([Unit Price] As decimal(12,5)) As Unit_Price From Prices","curTest2")
Select curTest2
Afields(laFields)
? laFields(1,1), laFields(1,2), laFields(1,3), laFields(1,4)
If you still see less decimal places, check SET FIXED and SET DECIMALS, which both influence the *display* of numbers.
Bye, Olaf.