A bit late to reply (I've been offline for a week) but have you considered doing separate SELECTs (without the UNION clauses) into VFP cursors and then doing the UNION from these cursors? That way you'd bypass the Oracle problem completely.

HTH
Barbara

>Thank you Barbara and Mark:
>
>For some weeks now I was having some discrepancies between VFP and Oracle8i, I even got a hold of Microsoft Tech Support to cooperate with this problem. They concluded it is a bug, and they didn't know if they will fix it into the next service pack or VFP release.
>
>The problem:
>Whenever you bring information with a SQL statement, everytime seems to work ok and you get the right results. Except when you accumulate records in Select -- UNION ALL -- SELECT -- UNION ALL -- SELECT and so forth statement sequence. Even using a single UNION ALL the problem already comes into play. The result is a cursor comes back with the right records but the original format of N(N,n) gets forced into N(20,0). So all the calculations and reports I may need to perform are already wrong since the data is wrong since its arrival into VFP.
>
>For now I think I can get away with making may UNION into an OR on the where clause, so records on the first criteria (First SELECT) will be brought in OR records on the second criteria will also brought in. Eye on the UNION ALL and UNION difference. With this I no longer use the UNION [ALL] clause since it generates errors.
>
>My Oracle-DBA suggested to use Oracle's ODBC driver, but that is another ball-game and the details are even more bug-to-address demanding. So, I kept the Microsoft's ODBC driver for Oracle since the same SELECT statements produce perfect results in EXCEL and ACCESS with UNION clauses.
>
>The DBSETPROP does not address which fields I want to have read-write which ones not and also does not allow me to define keys.
>
>Thank you again ...