I am working on a project where I will be provisioned a SQL Server 2017 database server. However, the only version of SQL Server Management Studio available to me is 2008R2. I could request a newer version but this may take 1-2 months before it is finally installed on my machine.
Am I going to run into compatibility issues? Are there any database settings in SQL Server 2017 I would need to set in order to use this?
I am pretty unfamiliar with the MS suite of database tools so sorry for my ignorance in this! Thanks
In response to comments:
I have a managed system so I am not able to install or run software that has not been "approved". I have tried the portable version of VS Code but that did not work for me. I am going through the process of requests SSMS 2017 but like I said in the question this will not be available for 1-2 months. In the meantime will SSMS 2008 work?
As unlikely as this may be, I happen to have two, and only two, versions of SSMS installed on my machine; 2008R2 and 2017. I'm in the midst of an upgrade project.
I opened SSMS 2008R2 and was to connect to and generally poke around on a SQL Server 2017 server and the related databases. I didn't do anything too complicated (a few SELECT statments & an UPDATE), but they worked. The objects I expected to be visible were visible. And I didn't have to do anything to make it work. It just worked.
Mostly.
Except that every time I right clicked on a table, an error box opened with this message:
Index was outside the bounds of the array. (Microsoft.SqlServer.Smo)
But if I hit the OK button, the box cleared and the desired right click menu opened and functioned. That will get irritating, but if you poke around in the Options menu, there might be a way to make it stop. I invested no minutes trying to do that.
At the very least, you should be able to work while you're waiting for your upgrade.
For what it's worth, I work for a government contractor and have the same level of security constraints you do, so I feel your pain.
Another approach is to run sqlcmd, which would have been installed with SQL Server 2008R2. I was able to connect from sqlcmd to a SQL Server 2017 Docker container (external/internal ports 1433). I did not encounter any errors/warnings when creating a database and table, and running some light queries.
Interestingly, I was unable to connect to the same server using SSMS 2008R2. Perhaps the protocol used or the security required (e.g., TLS 1.2) for the underlying connection was different. Clearly it works based on Eric Brandt's results.
Related
I've been testing DataGrip as a SQL IDE recently and I really like it. Particularly I decided to test it because of the multiple database type support.
One issue that I am having, and that is forcing me to keep SSMS open, is the SQL Server Agent. When developing I use it quite a bit to execute jobs from the agent. I cannot seem to get the SQL Server Agent to show up in the DB window in DataGrip (or anywhere else for that matter). Is this even possible? If not then this might be a deal breaker from me when working with SQL Server.
I have tried googling all the possible ways this question could be asked, and I've walked through the 'Connecting to SQL Server' instructions on the JetBrains site for DataGrip.
After doing some research and even reaching out to JetBrains themselves, it appears this is not planned to be supported anytime soon. It's kind of a shame this is the case, but I suppose there's only so much you can do. There is a plugin for this, but it will only work on 2019 versions of DataGrip, not the current 2020 versions. Here is the link for anyone using an older version of DataGrip that wants to incorporate this feature into their IDE.
https://plugins.jetbrains.com/plugin/13473-sql-server-administration-tool
In our company we have to support a large legacy system built on Microsoft Access 2010 as frontend and SQL Server 2008 R2 as backend. The backend SQL server runs on Windows Server 2008 R2. Currently our users works on Terminal Server sessions on a Windows Server 2008 R2. A couple of days ago we started to test Windows Server 2019 and Notebooks with the latest version of Windows 10. We recognized a big performance difference while executing the same Access databases on the different environments.
For instance the creation of a report takes 27 seconds (new environment) instead of 7 seconds (old environment). The database.accdb is identical, the backend is identical (still Windows 2008 R2 Server with SQL Server 2008 R2 and SP2), only the execution environment (Windows) changed.
Does anyone of you have an idea how to explain this?
In Access 2010 the SQL server tables are linked using System-DSN data sources. On the old environment ODBC is used (Driver: SQL Server, Version: 6.01.7601.17514).
On the new environment I tested the following drivers:
ODBC Driver 11 for SQL Server (2014.120.5543.11)
ODBC Driver 17 for SQL Server (2017.173.01.01)
SQL Server (10.00.17763.01)
SQL Server Native Client 10.0 (2009.100.4000.00)
SQL Server Native Client 11.0 (2011.110.5058.00)
I created a new System-DSN using the different drivers and updated the linked tables in Access. But in any case the performance is still bad. I also tested the latest version of Access which comes with Office 2019, but again it is slow.
Sounds like your terminal sessions are getting throttled. Despite the fact that you have a SQL Server back end, Access is still doing a fair bit of thunking with the result sets, so any resource throttling differences between your Server 2008 and Server 2019 policies could be choking Access in the new server.
I think your answer is going to be found in Windows System Resource Manager. The page says it's not being maintained, but following the "Recommended Version" link leads to a generic Server 2019 page. Here's another article about how WSRM might be throttling sessions: Using WSRM to control RDS Dynamic Fair Share Scheduling.
Compare the Weighted_Remote_Sessions policy in 2008 and 2019 servers. There's either been a change to the default settings or behavior or the 2008 server policy was modified in the past to get to the current performance level.
Ok, a number of things to check.
First thing to check:
Launch the ODBC manager and check if SQL log tracing is on. I don’t know why, but I see sql logging turned on.
You NEED to be 100% sure it is turned off.
You MUST launch the ODBC manager from the command line or start menu, since the one in the control panel is for the x64 bit version, and you are using Access x32 (I assume).
So launch this version:
c:\Windows\SysWOW64\odbcad32.exe
So VERY important to launch the x32. It is assumed you are using a FILE dsn. So check these two settings:
(Make sure they are un-checked).
Next up?
Link access using the IP address of the sql server.
So, place of say:
myServer\SQLEXPRESS
Use:
10.50.10.101\SQLEXPRESS
(Of course use the IP address of sql server, not the above “example” IP).
The above things are quite easy to check.
Still no performance fix?
Then disable the fire wall on your new Terminal server (I seen this REALLY cause havoc).
And, disable windows defender on the new TS server if running.
The above tips should fix your issues.
If above don’t work, then next would be to check the priority settings for the TS server (GUI over server).
However, I am betting the above checks should restore your performance.
Regarding the following images, I have obviously installed the Microsoft SQL Server, but I can't find the exe-file or anything named Microsoft SQL Server in the start menu.
Anyone who knows what to do to solve this, or do I need to install something more?
SQL Server runs as a service. You can start and stop it from windows services. SSMS is a gui tool for managing ddl (creating and altering tables and index's for example) and dml (writing queries to inquire, update or add data to databases).SSMS comes free with every edition of SQL server - perhaps you didn't tick a box when installing? You can also do this stuff the old fashioned way using sqlcmd from command line(DBAs love this for some reason) but for us mortals SSMS is much less of a struggle. As an aside there are other guis such as Toad (expensive) and Heidisql (free) amongst others which will do the job.
Looks like you have the engine. What you've got to do now is install SQL Server Management Studio: https://msdn.microsoft.com/hr-hr/library/mt238290.aspx
Looks like you have the various SQL Server components that are installed by Visual Studio (recent version) or SQL Server Data Tools (as used by VS).
I have heard other developers (i.e., not db administrators) complain over the years about the complexity of getting SQL Server installed and configured properly. I installed SQL Server 2014 about six months ago for a project that I'm no longer working on. I tried installing 2008 R2 with a named instance for a new project but something went wrong and I now have an inaccessible instance. My instinct is to remove everything and to just start fresh. Is this the right instinct?
If it is the right instinct, any advice on how to fully, fully, fully uninstall all instances of SQL Server? Seems every time I try to do so, there are some bits and pieces left behind and that gets me wondering if those leftover bits are causing trouble for subsequent re-installs.
If this is not the right instinct, please set me straight. I'm hoping that all of the answers will not be "db administrators are paid to be good at this so go find one." Of course, this is probably the best and most accurate response; but I would also like to solve my problem so if this is your response then I would be grateful if you could point me to a reliable, on-demand SQL Server admin service that I can consult to get this right -- I'm happy to pay for some high quality and efficient help.
Thanks for any advice.
Bob
If you are having problems accessing the server it's a good instinct to remove the name instance and install a new one. The reason you could not access the name instance could be compatibility problem b/n sql2014 and SQL 2008R2 or configuration problem. why do you really want to install SQL 2014 instead of sql2008? my be it's better to install SQL 2014 name instance.
please look at this link to remove the name instance SQL 2008.
http://thoughtsonopsmgr.blogspot.com/2012/10/how-to-remove-sql-server-instance-from.html
I discovered that SQL Server 2008 R2 isn't supported on Windows 10: https://support.microsoft.com/en-us/kb/2681562
So I uninstalled everything related to 2008 (which required a couple of reboots and further uninstall attempts) and then uninstalled everything I could find for 2014... and then I reinstalled 2014 from scratch... and I'm golden.
We run SQL Server 2005 exclusively for databases that we use (I'm trying to push to get them upgraded, but alas!). On the client side with Management Studio, are there any benefits to upgrading to SSMS2008 when only connecting to SQL Server 2005 databases? I've seen that Intellisense won't work, so I'm curious if it's worth the hassle.
Yes, there's quite a few improvements intellisense is definitely a big one for developers (Intellisense only works against SQL Server 2008 databases, unfortunately), but there are also other things like T-SQL Debugger, Activity Monitor, the Object Explorer Details
Also, multi-server queries, and the ability to color the connections (get a visual clue whether you're on dev, test or prod system) and a lot more.
See some good background info here at Simple-Talk.
It is up to you. My favorite is search feature. See link for details.
Having worked with SQL 2005 since it came out, upgraded my client tools to 2008 when it came out, and still not upgraded our server, I don't think it is worth upgrading, especially if you aren't moving to SQL 2008 on your server anytime soon. There is no real harm in upgrading, but you need to get familiar with a slightly different tool that IMO is neither worse nor better.
There are a lot of things to like about SQL2008 SSMS, even if you are connecting to SQL 2005 servers:
Customize the columns in the object views, including some very useful ones like DB size
When viewing a query execution plan, it will list any indexes that it recommends
Color-code server connections
Execute SQL statements against multiple servers
In our environment, we have a mix of SQL 2000, 2005, and 2008 servers, so I still use SQL 2005 SSMS to connect to all three (The new "Activity Monitor" in SQL2008 SSMS doesn't work for SQL 2000 servers.)
I don't want to sound like taking sides, but Toad 4.6 rulez! :-)