August 24, 2022 at 3:52 pm
Hi Everyone,
I am new to T-SQL and I need to write some basic code on a dev server. What is the best way to connect to the server ? Should I install the SSMS on my desktop and connect to the server or remote desktop to the server and launch the SSMS from the sever?
Also where do I save the code I write on my local desktop or on the server? how to separate my code from others developers?
last is there a built in code formatter in SSMS? if not, what you guys use.
Thanks a lot!
August 24, 2022 at 4:35 pm
Install & use SSMS locally.
Don't run SSMS on the server. You don't want the overhead or security risks of remote desktop, let alone SSMS, on the server if you can avoid it. The slippery slope might lead you to want to use a web browser on the server too.
See https://canro91.github.io/2020/09/30/FormatSQL/ for a couple free SSMS extensions that support code formatting. I haven't used them.
I do use RedGate SQL Prompt, which is not free, but is valuable.
August 24, 2022 at 5:01 pm
Also, check with the other Developers in the company. You should be checking your code into some form of source control. They should also have a "onboarding" process that lets you know all of this even if you've been at the company for a while.
P.S. I'm not sure how you figure you're "new to SQL". You have a few posts on this site starting more than 6 years ago. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
August 24, 2022 at 5:24 pm
Make Sense.
Do you know how much is the license for Redgate?
August 24, 2022 at 5:28 pm
Thank you and Yes I did posted something 6 years ago as I was assigned to take over a project but was later dropped.
August 24, 2022 at 6:57 pm
RedGate knows: https://www.red-gate.com/products/sql-development/sql-prompt/pricing
($179 for 1 license)
August 24, 2022 at 7:28 pm
On the formatting thing, you could try a free website such as PoorSQL.com with the understanding that there is no support if something goes awry. There are other sites that do as good or better. There are also some that don't do as well.
I find such formatters to be a bit of a pain in the ass when I need to deviate from what the formatter thinks is a good idea.
The other thing is, set SSMS up to convert tabs to spaces so the code looks the same even if you drop it into NotePad (or whatever) for whatever reason.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 24, 2022 at 9:38 pm
Thanks
August 24, 2022 at 9:39 pm
Sounds good. Thanks for sharing.
August 25, 2022 at 8:23 am
I find such formatters to be a bit of a pain in the ass when I need to deviate from what the formatter thinks is a good idea.
If someone on this forum posts sample code, which I then paste into my own local SSMS, I always reformat it (using SQL Prompt). My brain has grown used to seeing code in my own preferred format and if I reformatted manually I'd be wasting my life! That's not to say that SQL Prompt always gets things right – sometimes it puts in too many line breaks and indents, for example – but 95% of the time it's perfectly fine for me.
If you have a block of code which you do not wish to be auto-reformatted, you can put ('SQL Prompt formatting') tags around it.
If you have a team of developers working on the same code base, having a common formatting style (to be applied before any code is checked in to your VCS of choice) is a good idea for consistency. Agreeing on the nitty gritty of that formatting style is likely to escalate to civil war, however!
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
August 25, 2022 at 10:03 am
Another RedGate fan here.
More importantly, though, are there any SQL standards in your organisation already?
Anything and everything from naming conventions for tables, what capitalisation to use (e.g. camel case, kebab case, etc.) through to indenting of various lines and even naming standards for aliases in queries.
Once you decide on standard formatting, SQL Prompt from Redgate is excellent and can apply it to all your scripts. The time saved far outweighs the cost imho.
Oh and never use SELECT * in production code.
So many basics to consider that I've barely scraped the surface.
August 25, 2022 at 10:59 am
Oh and never use SELECT * in production code.
You have to be careful when using words like 'never'! In my opinion, there is nothing wrong with using SELECT * in an EXISTS clause, for example (because it does not get evaluated):
SELECT t1.c1, t1.c2
FROM t1
WHERE NOT EXISTS (SELECT * from t2 where t1.SomeId = t2.SomeId)
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
August 25, 2022 at 11:17 am
It seems we do not have any standard to follow (not even MVC). Do you know of any resource/link to best practice to follow with regards to naming convention.?
August 25, 2022 at 11:50 am
MarkP wrote:Oh and never use SELECT * in production code.
You have to be careful when using words like 'never'! In my opinion, there is nothing wrong with using SELECT * in an EXISTS clause, for example (because it does not get evaluated):
SELECT t1.c1, t1.c2
FROM t1
WHERE NOT EXISTS (SELECT * from t2 where t1.SomeId = t2.SomeId)
I'm comfortable with it - we use SELECT 1 instead of SELECT *
August 25, 2022 at 11:52 am
It seems we do not have any standard to follow (not even MVC). Do you know of any resource/link to best practice to follow with regards to naming convention.?
A comprehensive one is https://www.sqlstyle.guide/
Not that I agree with all of it, but that's part of the process of establishing a standard.
Viewing 15 posts - 1 through 15 (of 19 total)
You must be logged in to reply to this topic. Login to reply