>>With the exception of VFP's Logical data type, most of the data I will work with should be compatible. If the SQL field is varchar, I can live with it, as it should map fine to a character field in a VFP table. Same with Int to numeric. At least thats what I'm hoping. Some of the field names would almost certainly change, but as long as the data types are compatiable, I can't see any reason using CursorSchema to get back a desired structure table would be a problem.
>>
>>But, I've been wrong before....
>
>Varchar will map fine to VFP character. The problem here is when date gets sent back to the source table, these fields will be RPADded with spaces and defeat the purpose of varchar in the source table. This will kill any SQL querying these varchar fields because your field value must be RPADded with spaces. Otherwise, you will get no hits. Make sure you use the ConversionFunc of the CA to RTRIM() the values going back to the source tables of any varchar fields.



The big question is weather the CursorSchema is the way to go for getting the
data back in the structure I need, and it sounds like it is.

Here's the big picture. The GUI calls into the BO for data, passing any params, which
itself then passes the params to a SQL SP using a CA, which returns the data as XML
to the BO.

If any data type conversions are required, the BO will then convert the XML
to a table, make then necessary conversions, and then reconvert back to
XML for the return to the GUI.

If no conversions are required, the XML data is simply returned to the GUI.
I won't know on this until I get into the BO itself.

The GUI then recreates the table and binds the data to fields.

Sound like it will work?