I think I am seeing some very different SP stuff.... Hmm. My stored procedures are in an external .prg which the DBC uses as the "events file". In other words, I specified "use events file" in Database Properties, filled in some code for the AfterTableOpen and etc, and then added my own functions after that.

I can use ADO.NET to build some CommandText and run it against a SP and the SP runs, it seems like ADO.NET does not see it as a real stored procedure.... Maybe ADO.NET only recognizes SPs that are located in the DBC?




>Hi Steve,
>
>2) Just tested with released VFP8, it can read the list of stored procedures but the parameters cannot be retrieved. At least not using the Parameters.Refresh on the command object.
>
>A probable workaround is to read the entire stored procedure code with the CommandText property and then parsing to obtain the parameters. Although it wouldn't do you any good if you still can't specify parameters when calling the stored procedure.
>
>HTH,
>
>>Two-part follow up Q:
>>
>>1. What is the proper way to check the build number from a COM environment (eg., VBScript) and from a .NET environment (ADO.NET, C#)?
>>
>>2. With MSSQL, it's possible to discover Stored Procedure parameters and then create them with code and jam them into the SP. With the VFP8 OLEDB driver, is this possible? I think I'd want to interrogate the SP and then get all the column names into a System.Data.OleDb.OleDbParameterCollection or System.Data.OleDb.OleDbParameter, so I can then pass them back to VFP. Or is it possible to get all the column names from a VFP table so I could then create my own SQL-Insert string to pass to the provider?
>>
>>Thanks.
>>
>>
>>>>Are you guys planning on updating the version number (eg "VFPOLEDB.1b") for 8.0, or is there another way I should check the driver version before my code uses it?
>>>
>>>No plans that I'm aware of. You can always check the build number.