Do you have a comment or suggestion to improve SQL Server? We’d love to hear it!

Give us option to not have square brackets when drag&drop in SSMS

When we drag something from OE into a query window, then the identifier will always be enclosed in square brackets. Many of us do our due diligence and take care to use identifiers that do not require separators. These separators makes SQL code (a lot) harder to read, and we feel that we are punished with these square brackets. We don't want to do a search and replace all over and over again, when there could just be a setting in SSMS to not generate these.

61 votes
Sign in
Sign in with: Microsoft
Signed in as (Sign out)

We’ll send you updates on this idea

Tibor Karaszi shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: Microsoft
Signed in as (Sign out)
  • Eamon Nerbonne commented  ·   ·  Flag as inappropriate

    I mean; I guess *something* was implemented; but I'm not sure who want's this unfindable option in this form.

  • Eamon Nerbonne commented  ·   ·  Flag as inappropriate

    This does not appear to have been implemented. I tested on 17.9.1

    That is: dragging and dropping still surrounds all names with brackets; and furthermore the Tools > Options > SQL Server Object Explorer > Scripting options do not include any thing about any kind of brackets or escaping; nor does searching for "square" or "bracket" find anything useful in any part of the options pane.

  • Kevin Rowe commented  ·   ·  Flag as inappropriate

    Leave it to the MSSQL team to completely ignore a huge annoyance for it's users for over two decades and then, after all of the wait, we get a (nearly) worthless fix--as if they've never actually used their own program. This shouldn't even be an option but, since it is, it should be ON by default. It should also apply everywhere (not simply for drag-drop but also on ALL generated scripts throughout the program). It should also 'just know' when to use brackets because NO ONE wants brackets unless that is the only way to express the column reguardless of WHY it needs brackets (IOW, catch it when I name a column 'key' you freaking morons; as far as that goes, don't make words like, 'key' reserved; what's next? I swear if you make 'id' a keyword I will quit this job before using your **** product one more day). In fact, in 20++ years, you'd think you'd have taken it to the next (very simple) step and warn us when we are about to create a column that needs brackets for some reason and allow us to choose another name to avoid them as much as possible. FFS.

  • EskeRahn commented  ·   ·  Flag as inappropriate

    Nice :)
    But why not a much more general setting:
    * "Only add brackets on identifiers when they are needed"

    The brackets (or quoted identifiers) are a great idea IF (/when) someone have used odd characters like spaces, hyphens or reserved words in the identifiers. But for those of us that avoid that (and that would be close to everybody that do other types of code than SQL) - the auto-addition is mere pest that makes code much less readable.

    A typically scenario is that you start out with a "select top 1000" looking at a table/view, to quickly get the full fields list, and then develop it to real case usage. Here we every single time need to do two search and replaces to remove the brackets to make things readable... And IF someone have used odd characters on one field, we would need to reapply the brackets...

  • Mark Freeman commented  ·   ·  Flag as inappropriate

    Where in the Tools/Options menu tree? Search doesn't find it using "bracket" or "escape" as search terms.

  • Anthony commented  ·   ·  Flag as inappropriate

    Thanks for the location of the option. I agree with Allan and Vladimir, I was hoping for a more generic remove [] option.

  • Vladimir Moldovanenko commented  ·   ·  Flag as inappropriate

    I also hoped that this feature will be more generic, apply to scripting too. I keep my identifiers in compliance so I don't need all square bracketing. that is the first thing I do is to get rid of it, quite annoying.

    I would welcome no [] by default unless it is non-complaint identifier or reserved new word.

  • AllanC commented  ·   ·  Flag as inappropriate

    Thanks Vladimir Moldovanenko for the location on the Tools/Options/SQL Server Object Explorer node.

    This change is not as useful as I'd hoped however, as it does not affect SQL generated with "Select top 1000 Rows" - it does not obey those settings and the brackets still appear. To be fair these new settings have been added under the "Drag/Drop" area, but I don't see any equivalents in the "Scripting" section.

  • AllanC commented  ·   ·  Flag as inappropriate

    You say that ssms 17.6 has Tools/Options settings to turn off bracketing - WHERE?

  • Anthony commented  ·   ·  Flag as inappropriate

    Where exactly is this option on the Tools->Options menu. I can't find it.

  • Bill commented  ·   ·  Flag as inappropriate

    I know I am in the unpopular minority, but I prefer delimiting _every_ identifier. For me, delimiting makes searches easier, makes my SQL clearer (I got used to it), and future-proofs my SQL against the introduction of new reserved words. I also know most loath my style - that is quite OK.

    SQL Server 6.5's transfer data utility had a bug. If you were running it on the source server, and if you submitted an IP address for the destination server, it would parse your IP address' identifier as ".". Because it first dropped destination objects, the source database's objects were buggedly dropped, and no data was transferred to destination server (because source data was dropped). IOW, you lost all data, simply because an IP address was not properly identified.... Feel free to call me paranoid :).

    If the substance of the choice to remove a delimiter style is OK for most, then it is OK with me, as long as I have the ability to _always_ enforce delimiters :). As such, I add my vote.

    But what the MS Admin stated below ("ssms doesn't bracket those object types when you drag the folder to generate a comma-separated list"). I consider that behavior to be a possible bug.

  • JoeD commented  ·   ·  Flag as inappropriate

    We also do not need brackets for column types. For example, when scripting a CREATE TABLE statement on an existing table, there is no need for:

    [column_xyz] [decimal](16,2)

    All brackets unnecessary.

  • AdminMicrosoft SQL Server (Product Manager, Microsoft Azure) commented  ·   ·  Flag as inappropriate

    to clarify my last comment - ssms doesn't bracket those object types when you drag the folder to generate a comma-separated list, it does bracket them if you drag them individually. I will add brackets to view columns and udtt columns. I don't know if there are SQL operations that take lists of the other types as parameters to justify brackets.

  • Vladimir Moldovanenko commented  ·   ·  Flag as inappropriate

    According to MS everything can be identifier and it must follow identifier rules. If not then

    "When identifiers are used in Transact-SQL statements, the identifiers that do not comply with these rules must be delimited by double quotation marks or brackets."


    Therefore, all objects following rules do not need brackets and all objects not following rules need brackets. So we need an option to have brackets or not.

    Would this be correct?

  • AdminMicrosoft SQL Server (Product Manager, Microsoft Azure) commented  ·   ·  Flag as inappropriate

    Looking through the code, I see several object types that never add brackets when dragged, but I am not certain if the option should apply to them. That list currently includes:
    View columns
    UDTT Columns

    I suspect at least view and udtt columns should be bracketed when the setting is true, but I'm not certain about the rest. What say you?

  • Vladimir Moldovanenko commented  ·   ·  Flag as inappropriate

    When I script anything out using SSMS, removing [ ] is often the first thing I do, which is an annoyance. A setting in tools/options would be good.

  • Nobody commented  ·   ·  Flag as inappropriate

    Well, same for script Generators, semicola in generated script etc etc...

Feedback and Knowledge Base