Set FmtOnly deprecated in SQL 2012 without full replacement - by JimF42

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 782038 Comments
Status Closed Workarounds
Type Suggestion Repros 0
Opened 3/25/2013 8:35:21 AM
Access Restriction Public


Set FmtOnly supports stored procedures with multiple result sets, but the new replacement objects only ever return the first result set. 

While I agree that returning multiple result sets is not something to be taken lightly, it is sometimes the best solution to a problem because something must be done in a transaction and/or avoids multiple server trips to and from the client.

If FmtOnly is ever removed and no suitable replacement objects are created, then this will also break SQLMETAL (Linq to SQL) and Entity Framework v5, both of which support SQL stored procedures with multiple result sets. As stored procs with multiple result sets are, at times, unavoidable for us, we will be forced to return to using basic System.Data.SqlClient.SqlCommand objects again.
Sign in to post a comment.
Posted by Sandy Kalmar on 12/4/2014 at 7:00 AM
I found the voting button.
Posted by Sandy Kalmar on 12/4/2014 at 6:52 AM
So, if I'm understanding this correctly, the only solutions involve manually defining the result set at least twice; once in the stored procedure and once in the application that is consuming the stored procedure. And any time the schema of the result set changes, this has to be manually updated. This manual maintenance is the only workaround. Correct?

Is there somewhere we can vote to let you know how painful this is?
Posted by SAinCA on 4/15/2013 at 1:14 PM
And there you have it - another prime example of "we have better things to do than look at things we will break, are broken, are glaring omissions, are much-needed language enhancements, ..." and the list goes on.

Would Microsoft's SQL Programming Team care to actually BLOG about these so called "higher priority items" - if you do, be so kind as to link suggestions to them rather than have folks go hunt. At least, in this suggestion's case, there's a bit of "thinking" verbiage added in. Hopefully "thinking" turns to substance despite the "we don't have plans to implement it right now". So, the question remains, just what ARE you "planning on implementing"? How about you stop the infatuation with BI and Big Data for a while and give buckets of TLC to the CORE Engine, it's old, tired, falling behind, buggier than it used to be and is begging for a built-in asynchronous SP architecture that a user SP can use at will, not requiring some departure into Service Broker or SSIS. Now THAT would be a great feature! Serial processing within Stored Procedures in 2013 is SO archaic!

The issue of result sets in SPs doesn't affect just the "worlds" listed in the original post. SSRS is blighted by the inability to state within an SP "use this result set SSRS" - add "metadata" for this, too, ASAP, please....

Bulk closure of connect issues is getting too habitual, too indiscriminate, too much! I'm not the only one seeing the demise of this site's usefulness...

Come on, Microsoft, COMMUNICATE with substance not empty promises - how many times have you REALLY, truthfully, returned to a closed connect suggestion and re-evaluated it, much less those that have been opened for YEARS with scores of votes that sit as testimonies to indifference ( at 454 votes since 2008 and counting!)?
Posted by Microsoft on 4/12/2013 at 2:23 PM
After carefully evaluating all of the suggestion items in our pipeline, we are closing items that we will not implement in the near future due to current higher priority items. We will re-evaluate the closed suggestions again in the future based on the product roadmap.

For the new metadata discovery feature, our thinking is to provide syntax at the module level which will specify the contract (result sets returned). But we don't have plans to implement it right now.

Umachandar, SQL Programmability Team