I'm currently evaluating SF and one thing that does seem underdone is support for stored procedures as the data source for a BO. I've scanned the forum posts and it seems that support for stored procs has been on its way for a while but hasn't arrived yet.

Our interest in SF is for a tool we can use for future projects but also migrate from VB6/Janus/SQL2000 to VB.NET/DevX/SQL2005. We have some tables that are quite large (> 1 million rows) and, when we open a form on such a table the data source would be "proc name today - 7, today" - this would return all transactions 1 week old. While in the form the user could change to start and end dates for the transactions to whatever they want and, in form code, we simply change the data source of the Janus grid to "proc name new start date, new end date" and refresh the form. It just isn't clear to me how we would achieve this using SF.

From what I've read the only way we can automatically populate the data columns in a BO is to have view that is structured the same as our stored procedure. We certainly don't want to manually create and maintain the details of the data returned by our stored proc. So, is a 'dummy view' the only way we can go this?

Ben has already answered the followng question is correspondence via SF Sales but I would just like clarrification. As I understand it any data retrieval within a BO that uses stored procedures must be hand coded right down to creating named parameter lists, e.g. we can't just say our data source is: "proc name, param1, param2, param3" etc. The reason I would like clarrification is that I would have thought the DAL would be smart enough do the grunt work of creating paramters and assigning values - as a user I just want to say "here, take this, execute and give me the resultset". I don't see that I should be burdned with writing that type of code when, to me at least, it seems like the job of the DAL to do that for me.

TIA - Peter