What Version MS SQL Server and SSMS Am I Running? and Git with MSSSQL
-
Information I've run across searching other topics led me to want to find out what version I'm running. This was motivated by trying to learn if git/github would be good tools for version control on my database which led to the question of version.
I found an article that told me to run SELECT @@version. I did and found this:
That information doesn't seem to match what I've seen here for version information. My ignorance and inexperience are probably the reason; so feel free to educate me.
Version came to my attention because another article I found mentioned interfacing with Git through Azure. I don't have a need for a cloud-computing solution; so I don't know what to do with that information. The article did state that some versions of MS SQL Server include Azure, but I couldn't relate the information in that article to the info in the ss.
Questions:
- Do I even need version control with MSSQL/SSMS?
- Do I need to learn about Azure to use Git.
- Is it possible that MSSQL has built-in version control that I don't know about?
- What does the version info in the ss tell me? With that information, what forum should I be using for posting SQL questions on this board? So far, I've posted only in the General forum as my questions have not, to my knowledge, been version dependent or related.
- Maybe unrelated, but can I store the queries I copy or write in VS Code? . . . maintain them in a repo? Am I over-thinking this subject? Is there a built-in query management facility?
My gut tells me that version control is equally important for the database as it is for the HTML/CSS/Javascript/php code that my website is (being) built on.
Any clarification will be greatly appreciated.
Be kind. Be calm. Be generous. Behave.
-
@@VERSION returns the SQL Server database engine version.
For SSMS, you'd just click Help - About.
SSMS 21 (now in preview) adds built-in Git support.
You are right -- source control is as wise for SQL development as for other languages. Store each object as a separate file, probably with a separate subfolder for each object type (tables, views, stored procedures, functions, etc. It's up to you if you want to get as granular as storing indexes, constraints, foreign keys, triggers as separate objects.
I have used RedGate the SQL Source Control add-in for years. But will be looking into using the built-in SSMS support.
You don't have to use Azure to use Git.
-
@@VERSION returns the SQL Server database engine version.
For SSMS, you'd just click Help - About.
SSMS 21 (now in preview) adds built-in Git support.
You are right -- source control is as wise for SQL development as for other languages. Store each object as a separate file, probably with a separate subfolder for each object type (tables, views, stored procedures, functions, etc. It's up to you if you want to get as granular as storing indexes, constraints, foreign keys, triggers as separate objects.
I have used RedGate SQL Source Control add-in for years. But will be looking into using the built-in SSMS support.
You don't have to use Azure to use Git.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply