Poor Man 39;s Sql Formatter Download

0 views

Skip to first unread message

Derrik Thunderbird

unread,

Jan 25, 2024, 8:49:53 AM1/25/24

to soakastsuho

I've been using SSMS 18 with Poor Man's T-SQL formatter, and now I've had to switch to SSMS 19. Is there any free plugin that could help me out with keeping my SQL formatted consistently, without leaving SSMS? I can't afford anything other than free at the moment, sorry in advance for the difficult criteria.

With the permission of the PoorMans Formatter developer we have integrated it in our add-in "SSMSBoost". Recent version of SSMSBoost supports SSMS 2014, so you can use it to use Poor Man's formatter features. We have already developerd our own formatting engine, but have left "Poor Man's formatter" for backward compatibility, for those users, used to it. You will find it in formatter-styles drop-down as "Old fashioned formatting style".

poor man 39;s sql formatter download

DOWNLOAD ✔ https://t.co/c3OUzXrin3

A T-SQL formatting library in JS, transpiled from the C# library of the same name. Latest version: 1.6.10, last published: 5 years ago. Start using poor-mans-t-sql-formatter in your project by running `npm i poor-mans-t-sql-formatter`. There is 1...

Configure as required to your specific configuration, at least change the keywords to UPPER case! You can assign a short cut to format the SQL or use the menu, (Ctrl-Shift+P) and type in poor, or if you have just used it will be at the top of the list.

You can format SQL code using SQL Server Management Studio (SSMS) native options or format SQL code using a third-party SQL formatter tool.Please refer to this link:How to format SQL code in SQL Server Management Studio

ApexSQL Refactor is a free query formatter for Visual Studio and SQL Server Management Studio. It has over 160 formatting options. You can create your own formattig profiles and preview them. It comes with four built-in profiles. Also, you can try it online.

I recently completed the first non-beta release of the "Poor Man's T-SQL Formatter" library, SSMS Add-In, online formatter, etc, and I thought I'd post a quick announcement here in case it's useful to someone:

It's a "full script" formatter, intended to handle multi-batch scripts with complex DDL & DML; so far over the last 2 weeks, I haven't received any bug reports / cases where any SQL gets mangled, but I'm still waiting for interesting bug reports to come in! ?

The formatter is available for immediate use online at , and can be downloaded for use as an SSMS Add-In (2005 & 2008 supported - Denali support can probably be added pretty easily if anyone's looking for it). It's fully open-source (AGPL), so anyone is free to modify and redistribute it as long as they retain the license.

I use redgate sql prompt too. I also check every version of apexsql refactor (free), they have many options but I still cannot get it format the way I want it, but they have gotten better and better at it. None of the products format in a batch process too, that's why I am really interested in the formatter here.

Quick update on this thread, the latest version of this formatter was published today, including Notepad++ plugin, SSMS 2012/Demali support, a couple of translations (French/Spanish), pipeline support on the command-line formatter, a basic minifier, lots of bugfixes, and more bits & bobs:

Unfortunately the actual format of the code in your post was lost (and I forgot to respond here, sorry), but there's something in the latest version that may help you out: You can now specify to the formatter that there are regions of your code that shouldn't be formatted. Just put "[noformat]" in a comment before the block to be avoided, and "[/noformat]" afterwards (looks a bit like the IFCode used in the forums here actually:) ). Sample here: _amp_Tricks_8

ApexSQL Refactor is a free query formatter for Visual Studio and SQL Server Management Studio. It has over 160 formatting options. We can create our own formatting profiles and preview them. It comes with four built-in profiles. Also, we can try it online.

The installation steps are very easy, just double click on the .msi file andfollow the setup instructions. The interesting part is that the tool will installtwo components, a command line formatter and an add-on for SSMS.

#731724: Convert comment settings into a field to make them work with CMI and non-node entities Moves comment to a field api field. We would love to get the threading and pager settings into the formatter, instead of the field settings, this would allow this to be used in views etc ie anywhere else display settings can be configured
Also the UX around field settings is poor.
Also there is lots of juggling code around view modes in the comment formatter.
Lets clean it up

Move threading and pager settings into formatter settings (from field settings).
Move comment_new_page_count and comment_num_new to the CommentManager service
Change arguments to comment_new_page_count to include passing the number-per-page and the threading mode as arguments instead of fetching them from the field.
Update formatter-output to include data-comment-per-page and data-comment-mode attributes. Send these attributes to CommentController::renderNewCommentsNodeLinks() allowing it call the comment_new_page_count function with the new arguments (note it is the only place this function is called).

comment_new_page_count moved to manager service and new arguments.
Note CommentController::renderNewCommentsNodeLinks is the only place this function is called.
This will move settings from comment-field instance settings to one of comment-formatter or comment-type config-entity - so config schema changes

This change require to unify the output generation logic so formatter simply calls a function with parameters.
Also this change affects a way we generate a link to calculate a page for another formatter (links) so this a ONLY problem here

Yep, CommentController:renderNewCommentsNodeLinks() should then be updated to either receive the number of comments per page (meaning that they'd be stored in the client-side, meaning that a malicious user could easily try to overload the server by manipulating this number) or the formatter ID with which that setting is associated. The latter seems to be the safer option.

Not sure I get the new idea about node-links but originally the was idea to implement second formatter to use for teaser to display links only.
Also logic to count page and query thread could be changed slightly in #2068331-30: Convert comment SQL queries to the Entity Query API

To properly retrieve settings from formatter within other code this code needs to provide view mode or entity display with settings for formatter.
So the only question how to pass data-* attributes from formatter to node links

The problem is that comment field and node links are laying in different elements.
So when comment field is displayed (currently with field and comment wrappers) then some JS needs to pull this into node links.
But comments could be attached to any entity so this kind of formatter should work everywhehe

hmm comment_get_display_ordinal() and comment_get_display_page() going to be an issue. Called from the CommentForm submit handler...
Might need to inject the view_mode into the form when its displayed... should be doable, as form is tied to a formatter.

I'm no longer convinced that 'no per page' and 'threading mode' belong on formatter, but certain that links do (so they can be controlled with formatter options/disabled etc). In fact I think 'no per page' and 'subject' etc all belong on comment-type settings form now, not in field settings and only 'pager id' and 'link style' are formatter settings with no settings for field or instance at all - thoughts?
Moving those options to the comment-type is consistent with node-type etc.

This change is why I'm not certain that they belong on the formatter. The comment-form needs to know the number per page and threading mode in order to create the link fragment after a new comment is added - to redirect to that comment. On one hand we're already assuming that the comment came from the full-entity view mode (because we're using the commented entity's url info to build the link) - is it a bridge too far to assume that implies the default view mode? Or should we remove this redirect all together and make it configurable per-comment-type? Options would be 'commented entity in default view mode', 'comment reply form' and 'none'.

This seems like a can of worms. In order to make this permalink to the comment, you have to know how/where the comments are displayed, which is the "full" view mode setting on the entity bundle, I guess? This does seem like a formatter setting for that same type of comment?

As we discussed this options my vision was to place:
1) threading to comment type.
2) per page and form placement to formatter.
3) pager_id was introduced as quick fix but still there, no idea how to fix that properly.

Status:
CommentLinkBuilderTest fails - I believe that is because of the new CommentDefaultFormatter::LINKS_NONE formatter-setting which the test does not yet account for: CommentDefaultFormatter::LINKS_NONE outputs no link but (in at least one case) the test expects an 'access denied' message.

Form location also seems like a formatter setting to me **. However this has implications: when displaying a non-'full' view mode, we first need to check that view mode's formatter settings to see if comments are displayed there. If not, we must check the 'full' view mode's formatter settings to determine whether the "Add new comment" link should link to the form on the full node page (as is the default now/in D7?) or on a separate page.