>>>Jerry;
>>>
>>>Have you actually gotten Visual Basic to add a new record to a table that has fired the stored procedure? I agree with you that without VFP running, a VFP stored procedure should not fire.
>>>
>>>Bob
>>
>>I'm not so sure I agree. Using ODBC and with the appropriate DLL (VFPODBC.DLL, I think), I don't see any
>>reason why it wouldn't. Also why provide access to the DBC via a driver and not allow triggers, stored
>>procedures, etc. to behave as they should?
>>
>>I haven't tried this yet, but I will and if this does work, I'll post it.
>>
>>George
>
>
>Hi George;
>
>I haven't tried the VFP ODBC drivers (I mean, who needs to access Fox data using some kind of 'weaker' engine, he?) but I do remember doing it with Powerbuilder against some fox 2.6 data. Apparently some of the indexes were defined with Fox expressions and none of these would update because the function calls couldn't be located. Only indexes that didn't use functions could be updated. It makes sense because the ODBC driver would have to 'understand' a lot of potential commands and functions (Deleted()) was another killer, and who hasn't used that?)
>
>I don't expect fox functions to be supported by ODBC but it sure would be nice. But if I'm going to use ODBC (no Rushmore either) then I will go against SQL Server. And I won't use Acess against my data either (why get a boy to do a man's job?)
>
>Good luck. And let me know if it does work.
>
>Bob

Hello Jim and George,

Thanks for you replies. This is what I tried to test the VFP3 DBC Stored Procedures:

I created a test DBC called "Acme.dbc" and a table called "Customer.dbf". The Customer table had a
field called 'Custid' with a Default value of "GetID()". "GetID()" exists as a Stored Procedure in the database
container and generates a unique customer ID automatically whenever a record is appended. There is
about 3 lines of Fox code that generates this unique ID.

The Stored Procedure "GetID" works great whenever I APPEND BLANK to the Customer table
from within VFP. I have a few other Procedures in the Database container that fire on UPDATE
and DELETE triggers. But they work great, as expected from within VFP.

However I wanted to test the Stored Procedures in VFP3 with another app through ODBC.
Since I'm on a Win95 machine and I don't have another 32 app that will access the 32bit ODBC
driver, I decided to use VFP5.

Now I know VFP5 will open VFP3 databases and tables and the Stored Procedures will work fine, but
what I did was create a VFP5 Database and created a Remote View that used OBDC to link to the
Customer table inside of Acme.dbc. When I did that, and added or updated the Remote View inside
VFP5, the customer table was updated correctly and the Stored Procedures in Acme.dbc
did run and generate all the IDs they were suppose to.

I never had the customer file opened in VFP5, only a Remote view to the file. Does this sound like an actuate
test? Should I expect the same results using any other product and ODBC? Should the VFP Stored Procedures
fire off like this?

My other question is if the DBC and Tables reside on the Server machine and a client accesses the customer
table through ODBC and the Stored Procedures get fired off, where is the processing done? On the
server machine or the client machine? The Stored Procedures in question are written in VFP code and
sit inside a VFP DBC file. There is no EXE running, except for possibly on the client machine. But when
the request is made and sent through the ODBC drivers, how and where is the Stored Procedures processing
taking place?

Thanks,

Jerryt