>>Thank you I will have a look at it.
>
>The rule-of-thumb is to use about two more bytes on SQL as compared to dbf, so n(11,2) should be at least decimal(13,2).

Dragan, what I mean is that in VFP N () is bogus.
It's stored as a decimal, but as soon as is used to make a calculation, It is converted to float.
Conversely in SQL and .Net, the decimal makes calculations as decimal.
It follows that doing calculations in SQL and VFP with Decimal Datatype, can lead to different results.

>
>The other thing to worry about is transporting more complicated SQL statements. There are several gotchas
>
>- any iif() would have to be replaced with case when ... else... end
>
>- any nvl() with isnull()
>
>- any isnull() with "is null"
>
>- no boolean constants; if you want a where .f., it becomes where 1=2. If you need to check for boolean values, the boolean fields contain 0 or 1 but you can't do any arithmetic with them, not even boolean (i.e. you can't say "when a and b" - you must say "when a=1 and b=1"; "not a" is not possible, it must be "a=0")
>
>- the blank dates will be transported as 1900-01-01; no special date constants but strings which will be interpreted; preferably do them in a yyyy-mm-dd format or else you may get in trouble
>
>- date arithmetic is not an expression, it's a function dateadd() with a rather weird syntax but then it does have some neat capabilities.
>
>- in some places SQL may implicitly try to compare a string with a number and won't complain until it encounters something that's not exactly a number. Its rules are not what fox's val() does - val('1234x') is 1234 in fox, in SQL it's a damn error which can stop a job which was working for a long time. The text of the error may say which value it encountered, but it will never, under any circumstances (including torture, blackmail, polygraph test, truth drugs etc), confess in which column the error occurred.
>
>- all quotation marks around string constants must be apostrophes; a regular quotation mark is considered a field delimiter (because they had to accommodate Access ports, where fields called "% total" were regular). That's by default, which you can set differently for your database, but then it may revert to default without your influence, when the admin runs some script or upgrades something - burned myself on that and stick to default thereafter.
>
>- if you want to reuse the SQL statements written in Fox, make sure to remove continuation semicolons