Search

DDL : support both NO_WAIT and NOWAIT by aaronbertrand

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

8
0
Sign in
to vote
Type: Suggestion
ID: 520245
Opened: 12/14/2009 12:17:43 PM
Access Restriction: Public
0
Workaround(s)
Since some DDL has been implemented to allow an option called NO_WAIT (such as ALTER DATABASE), and other DDL has been implemented to allow an option called NOWAIT (such as RAISERROR), it can sometimes be quite frustrating when you switch from command to command.
Details (expand)
Product Language
English

Category

SQL Engine

Proposed Solution

Overload DDL that supports either NO_WAIT or NOWAIT to support both NO_WAIT *and* NOWAIT.

In the future, pick one style and be consistent, instead of letting the developer implementing the DDL to use his/her own preference.

Benefits

Faster Development
Improved Reliability
Other (please provides details below)

Other Benefits

Consistency
File Attachments
0 attachments
Sign in to post a comment.
Posted by Microsoft on 3/18/2011 at 2:02 PM
Hello Aaron,

Thank you for submitting this suggestion, but we're trying to clean house and remove items we feel we will likely not address given their priority relative to other items in our queue. We believe it is unlikely that we will address this suggestion, and so we are closing it as “won’t fix”.

This cleaning will help us focus on the high-priority items that we feel need to get done, and we hope that it help provide better clarity to you about the issues we will (and won't) address.

--
Umachandar, SQL Programmability Team
Posted by aaronbertrand on 1/11/2010 at 1:13 PM
Thanks UC!
Posted by Microsoft on 1/11/2010 at 1:06 PM
Hi Aaron,
Thanks for your feedback. Yes, this is on the list of things to fix similar to READONLY/READ_ONLY. READONLY is used for TVP whereas READ_ONLY is used in other places. Generally, for options we want to use underscore between two words/verbs. So we should stick with NO_WAIT and READ_ONLY. We will see about deprecating one of these option(s) and adding the other one as needed.

--
Umachandar, SQL Programmability Team
Sign in to post a workaround.