Nancy,

I was looking at this from this POV:

Suppose you have a team of VFP developers and you are migrating your VFP Client/Server app (VFP front-end, SQL Server back-end) to the Internet. You want to use .NET for this, but you also want to leverage the knowledge of your VFP developers. So you have a team of .NET developers (either by training some of your VFP guys, or hiring .NET guys) ... but because the VFP people already have knowledge of the data, it would make sense to utilize them to create Web Services to access the SQL Server data.

Anyway, just my 2 cents.

~~Bonnie



>Sorry that my point wasn't clear. I didn't say the method doesn't work. Try to look at it from a broader vantage point, which was, my example, a .NET programmer.
>
>My point:
>
>> I doubt that will be the recommendation for getting to, say Oracle data, or SQL-Server, or another data backend.
>
>A VB.NET programmer won't be pointed in the direction of writing a COM server to delete records in a data backend. At least, I doubt it.
>
>If your goal is to be able drop in back ends, yes, a com server can do it, +or+ you can spec that you'll stored procedures, in which case you shouldn't have to switch from using stored procs for SQL Server or Oracle to a COM server for VFP.
>
>IOW, to be very blunt and frank, that the storedproc doesn't work for a VFP backend in the .NET framework adds fuel to the argument we're a fringe language.