Settings and activity
5 results found
-
2 votes
An error occurred while saving the comment 
Jim Nguyen
supported this idea
·
-
9 votes
An error occurred while saving the comment Jim Nguyen
commented
I agree. I understand that those keywords are optional since they are the default. However, I like to explicitly script them out in case the default ever changes. Or, if you are not familiar with SQL Server and come from another database platform, it is easier to understand how that query works.
Jim Nguyen
supported this idea
·
-
18 votes
An error occurred while saving the comment Jim Nguyen
commented
I would like the reverse option as well. While I can understand the argument for always using block comments, similar arguments can be made for inline commenting. Ultimately, using one style of commenting is not always convenient in every scenario.
-
1 vote
An error occurred while saving the comment Jim Nguyen
commented
I don't get that issue when I type those two SELECT statements. The feature to automatically add the closing character and remove a duplicate closing character works correctly.
However, I was able to recreate the scenario that you are describing. The removal of a duplicate closing character does not work after I applied a style and tried to add a new literal as part of the existing SELECT statement. I was able to consistently recreate this problem following the steps below.
Type: SELECT 'Bill' AS FirstName
Apply Style
Edit Existing Statement by attempting to add a new literal column: ,'Bill' AS NewColumnWhen you add the new column, the ending quote is added when you add the opening quote. If you add a closing quote after adding the literal value, the feature to remove a duplicate closing quote is not applied, so you end up with two closing quotes. This occurred using version 10.3.5.
This only occurs with existing statements where the style was applied. For new statements, the features work correctly before or after the style was applied.
-
1 vote
An error occurred while saving the comment Jim Nguyen
commented
I would be careful with the resulting query in this recommendation. When you add the functions to the joining columns, it eliminates the SARGable characteristic and may impact the resulting query performance.
Yes! I have this exact same issue! This prevented my team from adopting SQL Prompt styles as part of our development process because everyone had different preferences for their Actions.
The original idea was to allow everyone to have their own styles when they coded individually, but apply the project style before committing the changes to the repository. This allowed a consistent format for the entire project.
Unfortunately, this approach couldn't be used with SQL Prompt because the Actions are configured per user and not as part of the shared project Style resulting in the scripts having inconsistent coding formats.