179 results found
-
Add one additional Parenthesis style
My Teams would prefer this option:
xxxxxxxxxxxxxx (
xxxxxxx,
xxxxxxx )Opening parenthesis on the first line, and closing parenthesis on the last line.
Second and following lines indented one stop. This display seems to strip out the leading spaces.
4 votes -
Parentheses
New Parentheses Style - #6 but ends like #1
Numbering starting at the top left as #1 and continuing to the right one as #5. With the next line starting as #6 and finishing on the right of line 2 as #9.
In the global parentheses settings, Lets make a #10 option which works like #6 in all ways except the closing parentheses is aligned with the beginning parentheses like it does on #1. Actually looking at the graphic that shows on #1, this looks like what I want, the trailing parentheses is below the first one, but #1 has…1 vote -
Add space between closing parethesis of a function call and FROM
Add an option to add a space between a function call, such as COUNT(), and FROM so that we don't end up with code like SELECT COUNT()FROM table. That doesn't happen when I select "Add spaces around parentheses" in the global parentheses options. The only way I've been able to get SQL Prompt to preserve that space is to select "Add spaces around parentheses" in the Function calls options, but I don't want a space between the function name and opening parenthesis.
4 votes -
conditions new line after
Currently we have a standard of placing new line before and after conditions with indent accordingly such that:
a=1
AND
b=2Current version only does:
a=1
AND b=2This is pretty much the only thing lacking from being able to just auto format all our procedures with a single click.
4 votes -
Provide support for "Suffixes to ignore" in "Insert code > Aliasing" options
We use a data warehousing strategy that creates potentially dozens of tables for multi-class entities in the data warehouse, so we have many tables that end in "core". This leads SQL Prompt to alias the object with a final "C" that we then remove manually. For example, our InstanceCore and Database_Core tables are aliased to "IC" and "DC" when we would prefer "I" and "D" respectively.
Can SQL Prompt's Aliasing capabilities be extended to support "Suffixes to ignore" just like the existing "Prefixes to ignore"?
1 vote -
Ignore Begin statements with CTE immediately after
SQL Prompt's "Insert semicolon" function behaves weirdly when a CTE is a the start of a control loop. For example, if I have this code:
IF (1=1) BEGIN
WITH numbers AS (
SELECT 1 AS num
UNION SELECT 2
UNION SELECT 3
UNION SELECT 4
)
SELECT * FROM numbers
END;SQL Prompt will format it as
IF (1=1) BEGIN;
WITH numbers AS (
SELECT 1 AS num
UNION SELECT 2
UNION SELECT 3
UNION SELECT 4
)
SELECT * FROM numbers;
END;While the code runs, I think the semicolon after "BEGIN" makes very little sense. First, the beginning…
3 votes -
Shortcut to move commas from start to end and vice versa.
I would like to only affect the placement of commas in a column list, without applying other formatting options. This would work similar to Ctrl-B, Ctrl-B to remove brackets or Ctrl-B, C to insert semicolons, in that no other formatting would take place.
There are times I have a rather well-formatted script but it has been written with commas at the start of the line and I prefer them at the end. A new shortcut would toggle placing commas at the start or end of the line without affecting other formatting within the script.
5 votes -
Additional Formatting Options
These are the typical formatting styles I use that I would like to see definable in SQL Prompt. Currently, I use a style that gets me close then manually format the remainder to the code:
Regarding the desired format of
1) SELECT, FROM, JOIN, WHERE, GROUP BY, HAVING, ORDER BY all lined up
2) TAB after SELECT, followed by first 'column'
3) Subsequent columns on separate lines and lined up with the first one.
4) TAB after any CASE followed by first WHEN
5) Subsequent WHENs lined up with first one
6) TAB before THEN (i.e. indented one tab from…4 votes -
Add option to wrap lines when concatenating strings
Sometimes I set a variable equal to many strings concatenated together using the "+" syntax. When I format with Regdate, there is no option to wrap lines in this case. Everything ends up on the same line as the SET, so the lines often get very wide and go off screen.
It would be great if there was an option to wrap text if things got too wide horizontally.
One solution would be a setting to format concatenated strings like this:
SET @Variable = N'String1'
+ N'String2'
+ N'String3'4 votesHi Amanda,
Would the ‘wrap lines longer than X characters’ option in the formatting styles help with this?
Tim
-
Top with parenthesis should be a formatting option
Changing
SELECT TOP 10...
to
SELECT TOP (10)... should be a formatting option.
11 votes -
Make parentheses rules customizable (where what applies) instead of a global setting
I have different wants for parentheses rules: Collapse short content or not, Having Parentheses on separat lines or leading the content, etc. It all depends on the context. But currently the setting is global.
I would like to be able to define one rule for, say, Primary Key definitions, and another rule for, say, the columns of a table.
I would want one thing for Control Flow sections, and another thing for Variables declarations.Today, I need to choose which one to be dominant (or stop using FORMAT SQL on the entire script, but just highlight the block where I…
3 votes -
format Window functions
SQL Prompt fails badly in formatting window functions. As these are present at least since SQL 2014, SQL Prompt should be able to interpret them and format them accordingly.
Example:
I would format the LAG() function as follows:
SELECT
myColumn AS realColumn
,LAG(myColumn, 1, 0)
OVER (
PARTITION BY someColumn
ORDER BY anotherColumn) AS calculatedColumnTry this with SQL Prompt - it's result is not very nice...
5 votes -
Custom values for VALUES clause
I write a LOT of unit tests, usually at the rate of 15:1 to 20:1 to my executing code. I have these standardized and templated to make them easier and more consistent to build. e.g. @GUID UNIQUEIDENTIFIER = NEWID(),
@Char CHAR(1) = 'A',
@Int INT = 1,
@Datetime DATETIME = CURRENTTIMESTAMP,
@Decimal DECIMAL(18,10) = 1.0,
@Date DATE = CURRENTTIMESTAMP,
@Time TIME = CURRENT_TIMESTAMP,
@Bit BIT = 1,
@Money MONEY = 1.00,
@Binary VARBINARY(18) = 0x01,These go into my VALUES clause for INSERT statements, but I current have to do all of this manually, which takes a LOT…
2 votes -
"Remove Square Brackets" option
The "Remove Square Brackets" option does not work for "CREATE EXTERNAL TABLE" statement.
Please try this option with the example below and nothing happens.
CREATE EXTERNAL TABLE [ft].[Account]
(
[AccountId] [bigint] NOT NULL,
[AccountType] [nvarchar] (50) COLLATE NOT NULL,
[AccountCreatedDate] [datetime2] NOT NULL
)
WITH
(
DATASOURCE = FinancialDB,
SCHEMANAME = 'Account',
OBJECT_NAME = 'Account'
);2 votes -
THEN expression on same line as keyword
Current formatting is:
CASE
WHEN 1 = 1 THEN
'Hello World'
ENDI need the option to put the expression on the same line:
CASE
WHEN 1 = 1 THEN 'Hello World'
END12 votes -
Apply SQL Prompt Styles with Code
I'd like a NuGet lib to be able to apply SQL Prompt styles to a folder of .sql files or a StreamReader string. I have a console app I'm using to produce a lot of Sql Files and I'd like to create a "everything on one-line" style that I use internally when processing things. There could be tons of other uses as well.
1 vote -
Format lists on a clause basis
I would like to control the list behavior on a clause by clause basis so that I can separate the formatting on my DECLARE statements differently than lists within SELECT and INSERT statements. As it stands, these are conflicting changes. So, the only way to get each variable declared on a separate line is to also have every column in other statements on a separate line. I'd like to be able to do BOTH of these:
DECLARE @GUID UNIQUEIDENTIFIER = NEWID(),
@Char CHAR(1) = 'A',
@Int INT = 1,
@Datetime DATETIME = CURRENTTIMESTAMP,
@Decimal DECIMAL(18,10) = 1.0,
@Date DATE…2 votes -
Closing parenthesis and content indention on APPLY/EXISTS not indenting
It seems that the contents and closing parenthesis of EXISTS and APPLY clauses is not being indented as I would expect. So either i'm weird....or Format SQL is doing it wrong?
I'm using (
.....this parentheses style
)What it's doing:
SELECT *
FROM tblA a
WHERE 1 = 1
.....AND EXISTS (
.....SELECT *
.....FROM tblB b
.....WHERE b.Col1 = a.Col1
..........AND b.Col2 = a.Col2
..........AND b.Col3 = a.Col3
)What I expect:
SELECT *
FROM tblA a
WHERE 1 = 1
.....AND EXISTS (
..........SELECT *
..........FROM tblB b
..........WHERE b.Col1 = a.Col1
...............AND b.Col2 = a.Col2
...............AND…3 votes -
Lists formatting for Columns and Parameters should be treated separately
The starting item in a List of Columns for a SELECT statement is fine to place on the same line as the SELECT, however, for EXEC <proc name that is probably longer> it looks odd to have the Parameters line up at the end. This should be a separate choice for EXEC Parameters. I chose the "commas before" style for most everything, but prefer the "default" layout for EXEC proc parameters.
4 votes -
Refactoring INSERT into MERGE
Refactoring INSERT into UPDATE is definitely useful, but most of us are familiar with these. The complex MERGE statement is a mess, and a clean way to generate that would be fantastic!! Especially since you can figure out the primary keys, etc..
4 votes
- Don't see your idea?