>This has been the biggest problem - when discussing ADO, or C/S in general. Yes, stored procs are powerful. When you talk about SQL Server, you are on solid ground. With Fox, well, it is not a server database period. Unless of course, you want a 3.8 mb ODBC Driver. Then, stored procs could be supported. This is why I refuse to demo ADO anymore with a VFP backend. At some point, you are going to hit limitations.
I don't think it needs to be that at all.
I'm not 100% sure, but I think if you have stored procedures and rules
as triggers they fire fine through ODBC. IOW, a lot of the functionality
is already there.
Just the DML would be fine - SQL commands and the base functions
to manipulate later. You know a lot of that stuff is in there, because
you can use it from SQL language (functions like ALLTRIM(), STRTRAN()
etc.). It seems silly not to expose at least what *is* supported.
I don't necessarily want OO in the ODBC driver (although it would be
nice) - just hte ability to basic code to handle tasks that are bitch
to do at the application level (like multi-select SQL statements and
cascaded updates etc. - if you haven't tried this with ADO and VB or
ASP get ready to write 50 lines or more of code that take 10 in VFP).
+++ Rick ---
>
>What VFP needs is an OLE-DB provider with the support for the most essential commands. You can't have it all - otherwise, we are talking about a big OLE-DB provider.
>
>This too gets back to my point about providers. ADO is just an interface - nothing more. What you are able to do is 100% dependent on the provider. If you were not able to do something with VFP using SPT - no way you are magically going to get those capabilities with ADO. You do however, get a much better interface. It does however, come at the expense of not having a native VFP cursor to work with...
>
>
>>I can see where the confustion is now. All along I have been talking about SQL server back. I've been tring to build a middle tier that converts ADO record sets (populated from SQL server) to VFP cursors. I then update the record set with values from the cursor and call rs.updatebatch. I can't seem to be able to control the concurrency constrants. Sorry about the confusion there.
>>
>>>Well, duh...
>>>
>>>Of course it works against SQL server. It doesn't work with VFP
>>>stored procedures...
>>>
>>>+++ Rick ---
>>>
>>>>Ooops I used greater then and less then signs that should have been:
>>>>
>>>>>nHandle = sqlconn('dsn name')
>>>>
>>>>>>> I'm not sure what you mean by this. In Fox we can call SP's through pass through and I think you can call an SP through the ADO command object. Why would you ever put a select and from clause on a SP? SP's are pretty much procedures like in Fox. You have parameters and return values. Maybe I'm just missing your point?
>>>>>>
>>>>>>How?
>>>>>>
>>>>>>It doesn't work for me and when I asked about this at MS a while back
>>>>>>I was told it's not supported.
>>>>>>
>>>>>>+++ Rick ---
>>>>>
>>>>>It works, just do:
>>>>>
>>>>>nHandle = sqlconn('
')
>>>>>? sqlexec(nHandle,"sp_who")
>>>>>
>>>>>This will return the results of sp_who to a cursor. You can also call any other SP you want. I tried a few of the sample ones that come in the Northwind database on SQL 7.0. I have not tried it through ADO yet.
