I need to work with numerous versions of SQL Server 2008R2 to current. I'm trying to learn and do more with PowerShell. So far, I have determined the following based on research. Can anyone please verify these and also add any specific details about backwards compatibility? Any additional help is appreciated.
SQL Server 2008R2 - PowerShell V2 (?) - SQLServerCmdletSnapin and SQLServerProviderSnapin
SQL Server 2012 and 2014 (?) - PowerShell v3 - SQLPS (load with Import-Module)
SQL Server 2016 and later - PowerShell v5 and later - SqlServer (load with Install-Module)
**New information below this point
I guess what I am asking is can I use the SQLServer with PowerShell versions prior to v5 and SQL versions prior to SQL 2016, or am I stuck with the commands that were included in SQLPS?
Or, if I am on Powershell v5 and SQL 2016, and write a script to manage SQL instances and databases, can I give it to people running SQL 2012 and have it work?
Can I use cmdlets like Add-RoleMember found in the SqlServer module, but not the SQLPS module be used, as long as I have them load the new module first, or does the new module only work on the newer SQL versions?
Also, is there a minimum version of PowerShell that supports the SqlServer module?
Related
How can we debug stored procedures in SQL Server 2018? As SQL Server 2018 and above versions do not have this option. Debugging makes life really easy. I have been trying to solve one problem for past one hour and if I could debug my stored procedure, I could have definitely save a lot of time. I did search a lot and did not find anything useful that could work.
Please do let me know if there is any way. Thanks.
How can we debug stored procedures in SQL Server 2018?
There is no such product as "SQL Server 2018" - I assume you're referring to one of the following:
SQL Server 2017
SQL Server 2019
SQL Server Management Studio 18
If you're referring to SQL Server 2017 or SQL Server 2019 then you can debug Stored Procedures by either:
Using SQL Server Management Studio 17.
Which may not work when connecting to a SQL Server 2019 instance, so YMMV.
Using SQL Server Data Tools (aka SSDT).
This is currently the officially supported tool for debugging SQL Server procedures and other objects in SQL Server.
SSDT is included in the free-as-in-beer Community Edition of Visual Studio without restrictions on its use in commercial settings.
But SSDT is not in any way a replacement for SSMS: SSDT only has basic tools for administering running SQL Server instances. So you'll need both SSMS and SSDT installed side-by-side.
If you're actually referring to SQL Server Management Studio 18 then you cannot debug procedures in SSMS 18 because Microsoft removed the feature for reasons unknown - I suspect perhaps involving the usual vague business reasons the veeps hand-wave with - because I cannot fathom any seriously good reason (though I agree the tooling was clunky, it did work at least).
To debug a procedure with SSDT you need to install Visual Studio (2017, 2019, they all have it) and select SSDT during VS installation. In previous releases of VS (like 2012, 2013, and 2015) SSDT used to be a separate download for VS but since VS 2017 it's part of the main installer.
When VS opens, dismiss the Start Screen and get to the main window, and go View > SQL Server Object Explorer, then connect to your server and the rest should be familiar to you.
As it sounds like you already have a substantial database project that exists in an extant SQL Server instance but also that you are not currently using SSDT - so I recommend you take this opportunity to actually move your project out of SQL Server and into an SSDT *.sqlproj - that way you can manage your database's design with source-control (Git, etc) and do local "builds" of your database (which will verify your code is valid T-SQL, it's saved me a lot of stress and trouble since I started using SSDT over 12 years ago) - it also makes publishing, deployments and schema changes a breeze (except for the fact the SSDT seems to get buggier and develops new glitches with each new release, ugh).
Faced the problem of using sqlcmd in sqlserver, but I do not know for which server versions it fits, I could not find it. this console does not depend on the version of sql server?
So, if I want to install sqlcmd on sqlserver 2003, it will work or need a version of the server> 2008 ???
Good day,
sqlcmd is not part of SQL Server but external utilities.If you want to use it then you need to install it (together with other tools like SSMS or separately). You can download the last version (at this time) from Microsoft directly from this link.
You should use the latest version even if you use older version of SQL Server (from 2008 and above) since the new version include support for new features. Do not use old version of sqlcmd to connect newer version of SQL Server even so it should work for basic tasks
--- update: adding some more information ---
Here you can find more information regarding how to use the tool:
https://learn.microsoft.com/en-us/sql/tools/sqlcmd-utility
I've been trying to test whether a project (DB, SSIS, SSAS) built on SQL Server 2014 will be compatible with SQL Server 2012. I've got a .dproj packed in dacpac format and when I try to run this from cmd:
sqlpackage.exe /Action:Script /SourceFile:"Project.dacpac" /TargetDatabaseName:DBName /TargetServerName:"DBName /p:BlockOnPossibleDataLoss=false /p:RegisterDataTierApplication=true /p:BlockWhenDriftDetected=false /OutputPath:Logs\Output.sql
I get a following error:
*** Could not deploy package. Internal Error. The database platform service with type Microsoft.Data.Tools.Sch
ema.Sql.Sql120DatabaseSchemaProvider is not valid. You must make sure
the servic e is loaded, or you must provide the full type name of a
valid database platform service.
I created a VM on Azure with SQL Server installed. Apart from that I installed Data Tools for VS 2012. I'm guessing that it might be compatibility problem, but maybe there's a workaround this without changing DT to a higher version? Any patch that could be applied?
You can install a more recent dacfx (sqlpackage) or you can copy the DAC folder from a more recent version to the deploy machine and use that instance of sqlpackage.exe to deploy.
You can also set the properties in the project itself to target SQL Server 2012 and it will validate that the T-SQL is correct for SQL Server 2012 and let you deploy to it.
There were lots of fixes between sqlpackage 2012 and 2014 so I would move them onto a newer version of sqlpackage even if you still target a SQL Server 2012 box.
This is only for dacpacs, not sure about the other projects.
I have database created on SQL SERVER 2008. I want to upgrade it to SQL SERVER 2016. what is the best way to upgrade the whole database?
Thanks in advance.
Migration can be done many ways from 2008 to 2016. In-house upgrade, backup restore, etc. Different approaches are explained here:
https://learn.microsoft.com/en-us/sql/database-engine/install-windows/upgrade-database-engine
But simple backup/restore approach is the always better in my practical understanding. Also It has links for SSIS/SSAS/SSRS if required plan for those. Each has different approaches...
Major things to consider are how to remove deprecated features and how to make use of new features:
Deprecated features:
2012:
https://technet.microsoft.com/en-us/library/ms143729(v=sql.110).aspx
2014:
https://msdn.microsoft.com/en-us/library/ms144262(v=sql.120)
2016:
https://learn.microsoft.com/en-us/sql/database-engine/discontinued-database-engine-functionality-in-sql-server-2016
You can use new AMR tool to identify what tables you can use for in-memory also you can do analysis of columnstore indexes etc using below:
https://blogs.technet.microsoft.com/dataplatforminsider/2013/09/17/new-amr-tool-simplifying-the-migration-to-in-memory-oltp/
I had big problems upgrading from 2008 to 20014 as it complained about 2008 SP2 missing, but there where additional messages about missing instance ID's or nothing needed to be installed.
The upgrade from 2008 to 2012 was a better move as the 2012 is probaly better designed to deal with a previous release.
Once 2012 was installed I moved to 2014 with no problem and did not have to care about attached databases. It just upgraded.
I had to use the "SQL Server Configuration Manager" to enable Named Pipes or TCP/IP connection in the "SQL Server Network Configuration" section, and enable the new SQL service .exe in the windows firewall.
To add it to the firewall the service exe "sqlsrvr.exe" was identified using the Windows task manager and using "properties" optaning the path to the .exe.
The installation makes you nervous but once installed you know SQL Server is one of the few Microsft products that does not bother you. It just works.
Instead of downloading missing servicepacks manually it was easier to run Windows update and have it suggest SQL server sevicepacks. Winows update actually helped before migrating to the next version.
Here is a nice chart of sql server editions with links to downloads:
Microsoft SQL Server Version List
I'm trying to do a SQL Server 2008 setup and I've been given a Cross Language Installation failure. More specifically:
Rule "cross language installation: failed.
the Setup language is different than the language of existing SQL Server features. To continue, use SQL Server Setup installation media of the same language as the installed SQL Server features.
I do not have SQL Server Express installed and I browsed through "Add or Remove Programs" and was unable to find anything that looked like it was a previous version of SQL.
Any tips?
I restarted the setup after facing the same problem, and I realized that man should not close the installation center till the setup process is completed. If you leave it open it will work.
Ensure that you have uninstalled all of your old SQL Server versions. Also you must restart the installer if you have not done that when you began installation.
All I had to do was exit the installer and start the process again. For some reason it worked the second time around.
I had the same problem today when installing SQL Server 2008 Express on a computer that has never had an instance of SQL Server installed.
I found that "Microsoft SQL Server 2005 Backward compatibility" was installed. I removed this via Add/Remove Programs and was able to successfully install SQL Server 2008 Express afterwards.
Change the Current Windows Language interface for the needed language you want to install.
That will make it possible for the Installer to launch the Localized version.
If you've previously installed SQL on the machine (or apparently some RedGate tools) have you checked for any SQL detritus in the registry?
If not then the MS forums have details of some reg keys to look out for, and some of the links are worth following for advice on what to delete from the registry.
On my installation of Sql Server 2008 Express, this was caused by having Sql Server 2005 Express Tools installed while trying to install 2008. Uninstalling 2005 Tools fixed the problem. I was able to keep Sql Server 2005 Express, including Sql Server 2005 Backward compatability; only had to nuke tools.