The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Why not adhere to Microsoft's support lifecycle for SQL Server, encouraging your customers to stay secure by running a version that's still supported and receiving security updates? In that case, the oldest version that should be allowed is SQL Server 2016 Service Pack 1, and even then only until extended support ends in July of this year. Why support a version of your own product that uses underlying technologies no longer supported by the vendor and with (possibly, depending on version) known security vulnerabilities?
I'm not a developer, I ask as a MSFT field engineer supporting other technologies what the challenges are for you to consider taking such a position with your customers. I'm fascinated when I run across conversations like this and wish to learn the thinking behind it in the hopes I can better support the developers I work with. Thanks!
Hi Jon and thanks for the reply.
It may surprise you to learn that many businesses are still using sql server 2008r2, which is the minimum that we officially support. We have nothing to do with a client's upgrade schedule, but basically have always just used whatever they had available, and back in the beginning that was sql 2000/msde.
IME, my customer's IT departments value stability and familiarity over support lifecycle schedules. They've probably never needed to open a support ticket for sql server anyway, and not many are concerned with security issues in older versions of a product that still gets the job done.
The history of this particular application may be of interest in this case. Originally, this application was developed to use an Access 2K database. A few years later, the decision was made to allow customer choice of either Access or SQL Server based on customer needs. Almost 20 years later, and 95% of the same queries work under both environments. IMO, that's a testament to the longevity of SQL standards and backward compatibility. I really can't recall when a newer version of SQL Server broke anything.
Personally, I favor sql server 2014 for development and for in-house or self-hosted applications. I have 2016 installed and available, but despise that version's SSMS as half the time it flakes out when starting. 2017 seems better but I only use it when importing from Azure.
They've probably never needed to open a support ticket for sql server anyway, and not many are concerned with security issues in older versions of a product that still gets the job done.
That reasoning is precisely why I have a job. Running old, out-of-support software puts an organization at a high level of risk, period, end of story. Especially when we're talking about something like SQL with a laundry list of vulnerabilities over the years ... hopefully they're at least at a patch level that supports TLS 1.2. I'm guessing their endpoint security is also incredibly weak, which increases the risk of keeping old server software on the network.
I can't tell you how many times I've walked into an organization recovering from a horrific intrusion because someone felt it wasn't worth the money or effort to get things to a proper level. "Support" means more than just "a need to open a support ticket", and dealing with the aftermath of an attack is almost always more expensive -- if not in real dollars, than in company reputation.
I'm not so lost in la-la land that I don't appreciate what I'm saying just doesn't compute for a lot of orgs. I get it. Doesn't mean it doesn't still amaze me beyond belief at times.
We lay out a upgrade schedule our clients must adhere to. Our code verifies server versions and will only run it the version is at a certain level or better. The client can opt not to upgrade to the current level our our software to continue using an old version but at some point they'll lose support for our code if it gets too far out of date.
It's the only way we found to make things reasonable. We need to develop against the current (and up coming versions) of Windows and the Database, we can't also maintain 10 versions back, things have changed too much over that period. We allow support of our current code and one major version back. When they upgrade our code it forces the upgrade on its dependencies.
Yep, this is something I implemented after this incident, but with a nice warning message box that they can screen capture and send to the appropriate people. Previously, we were only checking server versions and not the database compatibility option. It's hard to think of everything the first time!
This is the code I found ages ago to check the compatability level for the databases (good old 80 compatability messed a few things up for some reports I was doing) and if your using stored procedures for a login/access check this could be part of the result where your front end checks the data and goes 100 is the minimum compatability required for the successful running of this application, so if it breaks it's your fault (technically 100 is SQL 2008 but at least it's not SQL 2000).
Unfortunately this doesn't seem to be widely know (or checked for) since where I work we use a few different programs that I'm involved in and once I had set the compatability level to 80 on the wrong database (on my machine for testing) otherwise another program would behave really weirdly. The front end software suddenly broke the next day but nothing was coming up that there was anything incorrect with the system and configuration, which took about 30 minutes to track down all the stuff I had changed in the last few days.
WHERE name = DB_NAME()
Thanks Allan, I implemented that same code last week to identify those users stuck on 80 compatibility. I suppose it's one of the hazards of having an application that has been in use for almost 18 years now, first rolled out when sql 2000 was in vogue.
My guess is that through the years, as those customers migrated to newer sql server versions, the dbas simply forgot to check that comp. setting. Actually, this issue will resolve itself in the near future as more orgs migrate from sql 2008 as the 80 and 90 settings aren't even available under newer versions.
I used to able to come in sit down, have a and read my emails. This has stopped since I started on operation 'No Time, No Chance' where the deadlines were decided without reference to anything factual. This is not a fun project, we have to follow a set of standards that are so heavily worded that it is impossible to make sense of them. Hardware take it one way, Software the other (zero offsets) I'm in the middle trying to make sense of it while getting toxic Jira syndrome! Happy Days?
There is something called human rights, and according to the Geneva convention, you've got the right to drink hot coffee!
Anything that is unrelated to elephants is irrelephant Anonymous - The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944 - Never argue with a fool. Onlookers may not be able to tell the difference. Mark Twain
We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Hot Coffee.
Note that it's the pursuit of hot coffee, not the attainment!
Sent from my Amstrad PC 1640 Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
If you drink tea with milk, and your wife drinks her coffee black, then the black coffee may cool down more quickly (all other things being equal, black "stuff" heats up/cools down faster than lighter-coloured "stuff").
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.