Voice of the DBA

Author: way0utwest

  • Using SQL Compare in Read-Only Databases

    Recently a customer asked if SQL Compare and SQL Data Compare can be used with a read-only database as a source. It’s a good questions as I’ve seen some tools that create temp tables or do some other work in a source database, which might cause problems. Certainly someone running SQL Compare against production would want to ensure it works as a read-only application.

    This post will look at SQL Compare with a database set to read-only. I’ll do a second post on a login that only has read authorization.

    This is part of a series of posts on SQL Compare.

    Setup

    I’ve got a couple of databases that I use for Compare demos. In this case, compare5_prod and compare1. The compare5_prod is set to read only, as you see below.

    2024-10_0103

    My connection is as a sysadmin, but that doesn’t override a read-only database. As you can see below, Compare works fine:

    2024-10_0105

    This is because SQL Compare is not writing anything to the database. We read metadata and then process that in-memory on the client before returning the results.

    You can see this also works in SQL Data Compare.

    2024-10_0106

    Summary

    This was a very simple example, but I find that clients always would prefer to see examples already completed and proof that something works when they are evaluating software. Hopefully this helps answer this question.

    SQL Compare is an amazing tool that millions of users have enjoyed for 25 years. If you’ve never tried it, give it an eval today and see what you think.

  • Tech Debt Perils

    My wife and I have been thinking about some new audio equipment. We’ve been a little unhappy with our Bose soundbar because of the software flakiness and sporadic network connectivity issues. In looking around, I saw a Sonos product, but after reading a bit about the company’s recent history, I decided to look elsewhere.

    Sidebar: if any of you have recommendations that aren’t high-end $$$$ audio, let me know.

    I saw this article about some of the problems Sonos has had, and it resonated with me. I’ve been in a place where I’ve worked on software that had a lot of technical debt and needed to be changed/improved to help grow the company. Management was pressing everyone to get the software ready quickly, without more concerns about the customer experience or the quality.

    That seems to be what happened with Sonos, where they released new products and new software, with the software missing functionality that their customers needed. There were bug reports, bad press, lower sales, and canceled raises/bonuses. Those last ones, to me, ought to be completely focused on executives and managers, but I’m sure that’s not the case. Management rarely takes the blame, but ultimately they are responsible for hiring, training, steering the employees, and deciding to launch.

    The story reads like a summary of The Phoenix Project. Technical debt, poor project management, and pressure to increase sales combine to create a disastrous launch. It’s always hard to know where to assign blame, but clearly, good software engineering wasn’t a priority, nor was reducing technical debt. I know it can be hard to balance the need to alter software with the need to keep it maintainable, but in this case, they made poor decisions.

    The article says there were yelling and screaming in meetings, and concerns from developers about pushing back on senior leadership on the timelines and demands. Some of us might have been in those situations, and my experience has been if there is management that doesn’t value software engineering, any particular developer is vulnerable to a layoff or termination if they complain. If management doesn’t value software, they don’t value developers and think they can be easily replaced. I’ve seen quite a few companies start to fall quickly with this attitude when developers are not valued. I also see constant job openings and employees constantly looking for other opportunities at these organizations. People only stay long enough to find another job.

    Software is complex. It’s going to have some bugs. There are always tough decisions about which things to work on now and which to delay. I hear those conversations, and I find myself trying to balance the needs of sales and engineering. We need both, and we also need to ensure we can change directions in the future. Paying down technical debt should be a regular occurrence to ensure the software is maintainable and adaptable. I know that when we look to quickly take advantage of new opportunities, this can mean we’re adding new technical debt. Walking that line is the key to success.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • Denver Dev Day Oct 2024 Slides

    Here are the slides from my talk today: CI in Azure DevOps

    If you have questions, please feel free to contact me (top menu above).

  • Should I Learn PostgreSQL

    I got asked this question recently:

    I constantly see PostgreSQL on Microsoft slides, email, ads, etc. My MCADAA exam started with an entire section on it. I’m trying to determine if it’s worth focused study and training time. Roughly how much of the Azure cloud database space does PostgreSQL occupy? Should I include it in my personal training program?

    It’s a good question, though I am assuming that MCADDA is the Microsoft Certified: Azure Database Administrator Associate cert. That page describing the exam only mentions Azure SQL (SQL Server), and not PostgreSQL, so while I think Azure SQL for PostgreSQL is good to learn, I think the cert preparation needs an update if that topic is on the exam.

    In any case, should you learn PostgreSQL?

    I’ll give you the DBA answer: it depends.

    Ask yourself some questions:

    • Does your org use PostgreSQL or are they planning to do so?
    • Are you going to stick with your company for a few more years?
    • Are there more things you should be learning in the area you do work now?
    • Are there things you should become more skilled at that your company values?
    • Do you know what the opportunities are for people that know PostgreSQL well?

    Depending on the answers, I may or may not recommend you spend time there. If you have other things to learn that might be better at your current job, either the job you have or one you might want, then focus there. If your company does (or doesn’t) value PostgreSQL, then that influences your choice as well.

    PostgreSQL is growing fast. DB-Engines shows growth across a few platforms, and PostgreSQL is doing well.

    2024-10_0140

    The StackOverflow developer survey shows similar results:

    2024-10_0141

    However, those are general results. Your specific situation is different. Think about it and ask the question above to lots of people.