Voice of the DBA

Tag: software development

  • Moving to a New SqlClient

    DotNet developers, if you’re using the System.Data.SqlClient, stop. Move over to Microsoft.Data.SqlClient now.

    It’s easy to do, well, it’s relatively easy to say that. The actual work isn’t that hard, but it can be a challenge to move assemblies. In any case,  you need to reference the new assembly in your code, and ensure you’ve downloaded the NuGet package.

    Vicky Harp wrote a piece introducing this new provider, and you can find plenty of posts around the Internet (and videos) that explain how to change and why.

    Essentially, when you have the new assembly, you change this line:

    Using System.Data.SqlClient;

    to this:

    Microsoft.Data.SqlClient;

    If you haven’t fully qualified the assembly at the top and did it in code, you can search and replace.

    The big reason for the change is to allow the ADO.NET provider to release quicker and keep up with changes in technology. When the SqlClient has shipped with dotNet or dotNet Core, it upgraded rather rarely, and the pace of change was disconnected from features being added to SQL Server. Now Vicky’s team has responsibility here and is upgrading this at a more rapid pace.

    Let your friends know, and if you see System.Data.SqlClient in a code review, consider trying to refactor that out.

  • A Data Controversy

    Quite a bit has changed since this article about airlines and the US government.  Since very few people are flying, or even can fly, perhaps this disagreement is moot, but I bet it comes up again. Now, separate from the idea of the actual disagreement here, there is an interesting discussion about the data involved here. In short, the US government wants airlines to collect data about passengers to help track the COVID-19 virus. Airline executives say they can’t easily get this data, other than on paper, without spending a few months on development.

    Certainly having a way to gather additional information in a digital form can require some development work. There are all sorts of software decisions to be made about when, where, and how users might input information. We have mobile devices, kiosks, laptops, and more, all of which might require separate interfaces for software changes. There is also the testing, validation, and verification we want to ensure the software works well and doesn’t introduce instability.

    In today’s world, with growing legislation, there is also a question of privacy. These requests may or may not conflict with other laws that airlines are bound by. There is likely to be more conflict here as the world changes and laws are slow to change and converge in some type of consistency. Rapidly changing requirements, as have been pushed during the COVID-19 pandemic, can potentially put us technical people in a difficult position. We have to balance the urgency of meeting requirements with the potential liability of violating privacy. I’d hope we could find some balance there, especially in a crisis.

    We do need to be flexible and ready to adapt to changing requirements. If regulations change, our organizations ought to be able to prioritize these changes and rapidly deploy them. In today’s world, where many high performing DevOps companies can get new software out in hours or days, governments may expect large companies to be prepared to follow suit. In that case, especially where new data is needed, having a software development process that includes the database is critical.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • The Developer Arguments for Stored Procedures

    In all of the decades that I’ve been working with SQL Server, many people have been preaching the benefits of using stored procedures, In all of that time, the vast majority of developers that I’ve worked with have not wanted to actually write, or even call them. In one job, I offered to write all procedures within a day of being asked for them for one development team, and they still didn’t really want to use them. I made them do this by revoking permissions on many tables, but they still grumbled about the overhead of using procedures.

    I was having a discussion with a friend recently about using procedure, and he was having a similar battle. There was a group of developers that wanted to embed SQL  or use LINQ->SQL in their applications instead of calling stored procedures. It was frustrating, but he managed to secure a meeting to discuss the concerns with the developers.

    As we talked, we tried to frame the problem from the perspective of a developer. Why would or wouldn’t you want to use stored procedures? We had a few ideas, but really, I’m curious what you think today. Do you have any debate points that make sense from a developer point of view?

    I certainly do understand the ease of just writing SQL in whatever IDE you use for C#, ASP.NET, Java, etc. I get not wanting to open up SSMS, which can be slow. I also get that it’s nice to see all the code in one place, and not have some split between the application and the database.

    On the other hand, the idea of encapsulating code in the database feels a lot like the reason developers refactor code into new classes and methods to provide a clean interface between different types of functionality. Many times developers work with applications and code split among different components. On top of this, when you use procedures you push a lot of the performance work down to the database and on the DBAs.

    If you think stored procedures do or don’t make sense from a developer point of view, let me know today. Leave a comment in the discussion and explain your position.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • The Art of Commenting

    This week I noticed an article on comments in PoSh over at Simple Talk. It’s a nice look at the topic from Greg Moore and discusses the various ways that you can comment in the language. Since these scripts are often shared in a corporate environment and because they may outlast your tenure, it’s a good idea to include comments in your scripts and functions.

    The idea with PowerShell is similar to what you get from docstrings in Python. Since many people can script and build modules, being able to get some help and understanding of the code is important. Even for the modules I write, I may use them for some time and then put them down. When I go to use the same cmdlet or function again, I might not remember all the parameters or what I was thinking. If you’ve ever had to dig into code to understand what is happening, you quickly learn to appreciate those well documenting help strings.

    You may quickly learn to despise those that don’t write them well or even forget to include them at all.

    Writing a useful comment is a bit of an art. The author often needs to put themselves in the shoes of a less skilled individual, or maybe one that is context switching and needs to quickly understand what the code is doing. Not necessarily exactly how it works, but what it is supposed to do. This helps us decide if we can use the code quickly, or if we might need to dig in further.

    In the article, Greg points out some nice additional comment items, such as requirements for the module to run. These are the types of quick enhancements to code that greatly improve its useability for others. I’d highly recommend everyone learn about comment based help in PoSh, docstrings in Python, and other valuable commenting techniques in your language of choice.

    Learning to write good comments is a valuable skill, one that your team will appreciate. Since most of us work on teams these days, those skills just might make you more desirable for that next promotion or even a new position when word gets out. Practice becoming a good comment writer.

    Steve Jones