Home Dashboard Directory Help
Search

Set FmtOnly deprecated in SQL 2012 without full replacement by JimF42


Status: 

Closed
 as Won't Fix Help for as Won't Fix


2
0
Sign in
to vote
Type: Suggestion
ID: 782038
Opened: 3/25/2013 8:35:21 AM
Access Restriction: Public
0
Workaround(s)
view

Description

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.
Details
Sign in to post a comment.
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 (http://connect.microsoft.com/SQLServer/feedback/details/339410/please-fix-the-string-or-binary-data-would-be-truncated-message-to-give-the-column-name at 454 votes since 2008 and counting!)?
Posted by Microsoft on 4/12/2013 at 2:23 PM
Hello,
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
Sign in to post a workaround.