Hi,

I don't think there's a simple answer.

>>
The end consumer will be a webpage or thick client.
>>

Then first thought there would be deliver XML to the front end and, by extension, to use web services to do the job.

>>
i am trying to find a way to easily change from one database to another. oh, and it doesn't have to use ado.net, it can convert the cursor into xml or a string for all i care as long as it doesn't slow it down to much.
i guess my main question is, is using the cursoradapter a viable means for developing a data layer that needs to be able to point to different databases (not necessarily a mix for each build though, just if a client prefers we use sql server or whatever, instead of vfp)
>>

If you were dealing solely with a VFP Database then using VFP and cursoradapters would probably be a very viable option but if the ability to use different data sources on the back end is important then I'd be inclined to use .NET ASP/ADO on the server. Using the .NET SQL Dataprovider is a very efficient way of attaching to MSSQL data and using the OLEDB data provider with VFPOLEDB should work well for a VFP database (especially since VFP9 makes it possible to return a cursor from a stored procedure).

To be honest I've not used VFP Cursoradapters in a working environment. Got some old VFP MTDLL's (just using CURSORTOXML()/XMLTOCURSOR() etc) delivering web services directly and have moved some of these to work via a simple ASP.NET 'wrapper' and am currently re-working them yet again by moving more logic to .NET and just using VFP stored procs via VFPOLEDB as outlined above.

Of course if the primary front end is a VFP based fat client and the back end data will usually by VFP data then I'm advocating a pretty round about way of getting from one to the other. ATHOTD there a lots of ways to skin a cat and personal prefences play a part...

Regards,
Viv