this post was submitted on 18 Jun 2024
326 points (99.1% liked)

Technology

59720 readers
6095 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 4 points 5 months ago (2 children)

I have never had a problem upgrading a SQL server. Granted, we aren't talking about anything fancy like database sharding, but the janky applications I work with have never complained.

[–] [email protected] 5 points 5 months ago (1 children)

I think in 99% of use cases, upgrading isn't a problem. Most of the time new SQL versions are backward compatible. I've never personally had a problem upgrading a database for a product that expects an older version.

They do have compatibility modes too, but those only go back so far too.

But, I think companies with their production databases for perhaps older complex systems are likely very weary of upgrading their working database. This is most likely where this situation comes from. Imagine being the person responsible for IT, that upgraded the DB server and database to the latest version. Everything seemed to be working fine. Then accounts run their year-end process, it falls over and now there are months of data in the newer version that won't work properly. It'd be an absolute pain to get things working again.

Much safer to leave that SQL 2005 server doing what it does best. :P

[–] Mbourgon 2 points 5 months ago

It’s not just SQL, it’s frequently the OS. Corporate tools don’t support the new OS so you install the “supported” OS, which is now several years old, and which only supports the next version or two of SQL Server. Microsoft also didn’t help things with 2012R2, which was 2 years later but had the same EOL as 2012.

And yes, you can set compatibility level on the database, but there are still edge cases where the engine version matters. And the business prioritizes, but upgrades are lower on the list than money-making features.

[–] [email protected] 2 points 5 months ago (1 children)

Apparently, it is not only my oberservation, but the article says similarly:

The inconsistent approach to backward compatibility in decades past may also have played a part.

However, I'm not a db admin and my perspective might be biased (infosec).

[–] [email protected] 2 points 5 months ago

I don't know what they're talking about there, but that might just be ignorance on my part, because I'm not a database administrator. For the basic use cases, SQL hasn't changed in decades. For simple applications you could even change from MSSQL to MariaDB to postgres and make only minor changes.