February 29, 2016 at 12:45 pm
I'm planning to take some time to check this out for myself, but I'm also looking for information from folks here.
I'm going to be migrating from SQL2008R2 to SQL2014 in the coming months, and because of various processes here I'm not expecting to have SSMS 2014 on my workstation anytime soon.
Now, I know I should be able to do the majority of day-to-day tasks by using SSMS 2012 (yes, I said we're migrating from SQL 2008, but until some things came up we were planning to go to SQL 2012, so I got SSMS 2012 in that time) but I also expect there's going to be some things that don't work, or don't work as expected.
For me, I'll be able to RDP into the servers, if needed, to use SSMS 2014, the devs I support however, won't have that option.
As an example of something we ran into with SSMS 2008 to SQL 2012: editing tables in SSMS didn't work, and they couldn't upload SSIS packages.
We can work around the problems until we can get SSMS 2014, but if we know ahead of time what might be an issue, it'll make for a smoother process...
Thanks,
Jason
February 29, 2016 at 5:34 pm
So, did some quick-n-dirty testing this evening, and it looks like the same things that don't work when managing a SQL2012 install with SSMS 2008R2, don't work with SSMS 2012 managing SQL 2014.
Can't connect to SSIS (thus headaches with packages,) can't use SSMS to design tables (my poor, poor devs would need to script them out,) but the majority of the basic stuff can still be tackled.
March 1, 2016 at 4:33 am
The basics will work. Mainly T-SQL is going to be fine. But I'd just get the 2014 SSMS out to people. The backward compatibility works, so it's safe.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 1, 2016 at 5:06 am
And no GUI for Extended Events (or any of the newer features)
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
March 1, 2016 at 5:30 am
Grant Fritchey (3/1/2016)
The basics will work. Mainly T-SQL is going to be fine. But I'd just get the 2014 SSMS out to people. The backward compatibility works, so it's safe.
Yeah, the end-goal is to get SSMS 2014, but the way the process works around here, they need to do a "build guide" before they'll even contemplate putting it on workstations, which involve vulnerability scans, patch, scan, patch again, scan...
Worse is half the time the people who are required to do one of the steps (say the scans,) can't / don't get to it in a timely manner, so then the poor schlub trying to do the build guide has to start over from scratch because now the last scan is "too old" to start from...
And yes, it's a completely jacked-up, crackpot, PITA of a "process" that there's little chance of it changing any time soon...
(And if you know where I work, well, there's your answer)
March 1, 2016 at 6:09 am
jasona.work (3/1/2016)
Grant Fritchey (3/1/2016)
The basics will work. Mainly T-SQL is going to be fine. But I'd just get the 2014 SSMS out to people. The backward compatibility works, so it's safe.Yeah, the end-goal is to get SSMS 2014, but the way the process works around here, they need to do a "build guide" before they'll even contemplate putting it on workstations, which involve vulnerability scans, patch, scan, patch again, scan...
Worse is half the time the people who are required to do one of the steps (say the scans,) can't / don't get to it in a timely manner, so then the poor schlub trying to do the build guide has to start over from scratch because now the last scan is "too old" to start from...
And yes, it's a completely jacked-up, crackpot, PITA of a "process" that there's little chance of it changing any time soon...
(And if you know where I work, well, there's your answer)
Sounds like it could be one of several places I've worked... You have my sympathies.
Thomas Rushton
blog: https://thelonedba.wordpress.com
March 1, 2016 at 6:24 am
There's no handy Stop button in the SQL error log, but I suppose Developers won't have access to that anyway?
March 1, 2016 at 6:51 am
Beatrix Kiddo (3/1/2016)
There's no handy Stop button in the SQL error log, but I suppose Developers won't have access to that anyway?
Correct. Devs get Public and nothing else at the instance level.
Viewing 8 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply