Voice of the DBA

Author: way0utwest

  • It Just Works

    Access is a database application that just won’t die, and it’s the subject of a short piece that discusses the reasons why the platform is still in use and thriving in some cases. I wonder how many of you still use, or support, databases that are built in Access and used by people in your organization to get work done.

    Like many SQL Server pros, I’ve often dismissed Access as a poor tool for running an important database system. However, that’s been based on my experience with larger organizations that need to scale up a system for multiple people to use concurrently. Access doesn’t do that well, though it can certainly handle a small number of people easily.

    Perhaps my disdain is also born from experience with Access being used to edit data in SQL Server and taking table locks. That usually builds a blocking chain that ends with my phone ringing, something I try to ensure doesn’t happen. However, that’s a broad brush against Access. I have a SQL Server DBA friend that used to use Access to edit lookup data. This person would even give a form in Access to a few employees to allow them to maintain some data in SQL Server. Without any issues.

    Access is easy to get up and running, which isn’t something I’d say about SQL Server. I’ve used most versions of SQL and built applications on the platform. Getting going quickly, without overhead, isn’t something I think about. Even security, which I understand well, isn’t simple to explain or get right. I see plenty of people struggling with this constantly, which is likely why many vendors end up using the “sa” account.

    There are lots of reasons why SQL Server (or some other server) is a better database platform for an application with any widespread usage. There are also reasons why Access is a good platform for small systems. I’ve run into a few Access MVPs that are still building and maintaining applications for small customers, with no shortage of work and plenty of accolades from their clients. Maybe the last part of the article says it the best why Access is still in use: ” the attraction of something that “just works” has turned many ordinary technologies into overnight sensations.” I couldn’t say it any better myself.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Learn from the Troubles of Others

    Some of us have experienced lots of strange issues while working with SQL Server. Some from poorly configured or coded systems, some from heavy workloads, and some from bugs in the code. Encountering and solving those problems, even if self-induced, is one way that we have learned about the best ways to ensure SQL Server performs extremely well under many situations.

    Others of us have had few issues and found SQL Server to be a very stable and solid product. In fact, I often find someone posting about an issue has been running an instance for years without any issues until one day something breaks or reaches a tipping point. I’ve seen this with numerous instances that were installed with plenty of disk space and without log backups. They may run for a year or more before logs fill and cause issues.

    It can be hard to plan for the unknown disasters that might be lurking in your system, but one thing that might help you think more widely about potential issues is reading posts about the issues others have encountered. Certainly plenty of people blog about these, and we often put out in our Database Weekly newsletter, but there are other good sources.

    The CSS SQL Server Engineers write some interesting posts about issues they’ve solved. Availability Groups are important and harder to configure and manage than many people realize. I caught a really interesting post about strange behavior under high workloads. This was with In-Memory technology, which I am starting to see more people experiment with implementing. This is the type of post that might give you pause, but also help you plan for and be aware of an issue that could occur.

    In this case, it’s a bug and a CU fixes the issue. Without knowing this, you might open your own case and spend time debugging the issue. Reading an article like this might trigger you to go back and check on it if you experience the issue. The bigger advantage I see here is there is a lot of information about how to measure and understand the performance of various parts of an AG system with code and linked articles here. While others might tell you there’s a CU to fix a specific issue, the knowledge you gain about how to dig into the performance of your AG setup could help you solve lots of other types of issues.

    Keep learning and keep reading. There’s lots of amazing SQL Server information on the Internet for you, and we’re happy to keep bringing some of it to you at SQLServerCentral.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Getting Started with SQL Prompt 10

    This week we released SQL Prompt 10, which is an exciting milestone for us. I remember when I discovered this little gem for Database Weekly and sent it over to Redgate as something they might want to buy. They did and have made dramatic and amazing improvements over the last decade+.

    I’ll have a few notes on new features, some of which have been leaking out in v9 already. We’ve started to get away from holding all features until a new release and slowly trickling them out, sometimes as experimental feature flagged items.

    There is a new Welcome window,which I think is a nicer way to show off a feature than the tool tips. I can see a few things at a glance, have some links, and get this back from the SQL Prompt | Help menu at any time.

    2019-11-08 08_31_30-SQL Prompt - Welcome - Microsoft SQL Server Management Studio

    I think SQL Prompt is the best intellisense tool for SQL Server, and many people agree. If you’ve never tried it, you can get an eval today and see what you think. If you already use it, know that we’re still investing in the tool and driving it forward for the new data platform on SQL Server 2019.

  • Agile Job Descriptions

    Most of us have applied for a job at some point in our career. In my youth, this was finding a listing in a newspaper or on a storefront and then going in to apply in person. At times I didn’t really care what the job description was, as I needed a job. Usually the title was enough to decide if I wanted to be a “waiter” or “cashier” or “laborer”. I am somewhat glad those days are behind me, at least for the most part. My wife usually expects her fence builder and cook to be regularly available.

    In the technology fields, we often have very detailed job descriptions. In fact, I think most of the job descriptions I see have had too much input and ask for more skills than any individual is likely to have. In my experience, if I meet at least 50% of the required skills, I apply. I’d encourage you to do the same, as many of the requirements are flexible as hiring managers realize they can’t find someone that meets 100% of their desires.

    Today, I’m wondering if any of you ever look back at the job description that you were hired to fill. Does your current work match what was written when you applied? Did you end up doing more or less of what was listed? Or has the job evolved as you’ve been in this position. Would you still be qualified for this position? Over-qualified? Or maybe you feel you’re still not quite qualified enough?

    I’m kidding about the last one, though there are always people searching for a challenge and enjoying the struggle of learning and growing their skills. In fact, some of the most talented people I know have had lots of success and still struggle with impostor syndrome, which I think drives them to be better. Or maybe some just have the Jerry Rice training habits.

    Take a few minutes today and think about your job and the description that was written for it. Has it evolved, or is it what you expected?

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.