>>Hi Cetin,
>>Thank you very much for your input and for sharing your code.
>>I am using a Cursor Adapter in a data-driven mode. All fields that have to be in the SQL Select are in a meta .DBF table. So, for calculated field (like the one I have asked in this thread) I use the "Cast(0 as bit)" in the field_expression column of the DBF. My solution is either not to use the calculated column, when the back end is VFP. Or, add another field to the meta DBF (e.g. VFP_EXPR) and enter the "Cast(0 as Logical" in this field.
>>Then, when the CA is initialized, both - VFP and SQL - will be covered.
>>But I have not yet decided what to do for VFP.
>
>I am also using CursorAdapter + direct commands like SQLQueryInto (does a select into a cursor with parameters), SQLNonQuery (runs non query command with parameters like update, delete), SQLInsert (as name suggests) and SQLExecuteScalar.
>Saying meta, do you mean CA classes and Cursor structures? In my case, I found it more appropriate to have 2 sets of CA classes, CA_VFP.prg and CA_SQL keep them. I instantiate the CA from one of them based on current 'app mode'.

Almost everything in my is data-driven.
There is one DBF (I call it CA Dictionary) file that has all fields for all tables of the application. When the CA cursor is initialized the list of fields (for a given table) is created based on the records in the CA Dictionary. There is a column CAL_FLD where I have expressions; that is, fields that do not exist in the base table. And this column is only used when the app works against SQL Server. So far, this approach works for all cases.
And, as I mentioned, I can add a new field to the CA Dictionary, for calculated fields with VFP.

So far, I found a way to use the app with VFP without this calculated field. But time will show.