Author: way0utwest

  • The Book of Redgate: Get the right stuff done

    Another of our values:

    2025-10_line0108

    The facing page has this quote: “We admire people who get stuff done. While there’s a place for planning, thinking and process it is better to try – and try well – and fail than not to try at all.”

    This is an approach I use in lots of my life. Not always, but I do try to get things done, and make a strong effort in doing so. I ask the kids I coach to do the same. The effort is what matters; it’s more important than the outcome. The outcomes matter, but we can accept mistakes.

    This is one of those values I think ought to be more prominently displayed and discussed, in most organizations.

    I have a copy of the Book of Redgate from 2010. This was a book we produced internally about the company after 10 years in existence. At that time, I’d been there for about 3 years, and it was interesting to learn a some things about the company. This series of posts looks back at the Book of Redgate 15 years later.

  • JSON Has a Cost

    JSON seems to be everywhere these days. Many application developers like it across all sorts of languages, C#, JAVA, Python, and more. They use it for transferring information between systems, and are comfortable serializing hierarchical object data into JSON from text and de-serializing it back into its various elements.

    For those of us working in relational databases, JSON seems like a blob of information that isn’t easily queried, indexed, or stored. We prefer working with a relational set of data, which brings us into conflict with software developers. We’d like them to convert their objects to a relational structure, and they’d like us to just work with JSON.

    SQL Server has added new JSON functions in SQL Server 2025, expanding the JSON capabilities from previous versions. PostgreSQL has JSON types for a few versions, as has Oracle. Lots of applications are storing JSON data in databases. Unlike XML, however, JSON seems to be working well (overall) as a data storage mechanism.

    Or is it?

    At a recent conference, one of the speakers noted that we do a lot of data movement these days, and there can be a high cost to this as we pay for both compute and network. This data movement often incurs a query cost to get information from the source system. JSON can exacerbate this issue as we may send more data than necessary, and we might find our compute engines don’t support predicate pushdown. Even if we index the JSON, we might still end up querying more data from disks to get what we need. Especially as we move a lot of data to warehouses and lakehouses.

    Using JSON can slow things down. It’s nice for storing a bunch of information quickly and easily, but as we need to work with specific parts of a JSON document, we would likely be better off de-serializing the important pieces into more structured formats that prevent duplication, are easily indexed, and can achieve quick query performance. Everything becomes a little smoother.

    JSON is great, and I do like it, but it’s not a substitute for relational systems and relational models.

    Steve Jones

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

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

  • Renaming a Column: #SQLNewBlogger

    This is a short post on how to rename a column in a SQL Server table.

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    I Typo’d a Name

    I was testing something recently and created this table:

    CREATE TABLE BinaryData
    (
         BinaryDataID INT NOT NULL
             CONSTRAINT BinaryDataPK PRIMARY KEY,
         Emoji VARBINARY(16),
         UserPic VARBINARY(MAX),
         BinaryTexet VARBINARY(250)
    )
    GO

    I didn’t realize at first that the last column was BinaryTexet and not BinaryText. I added data, wrote a few queries, and had done some testing. Using SQL Prompt is great, but it hid my silly mistake. As I went to send this code elsewhere, I realized my mistake.

    I could have dropped the table, created a new one with the right name, saved the data or moved it, and done more, but that’s a lot of work. It also might cause me issues with the dependencies from other code. Not this column name, as any dependencies have to be fixed, but I could have other FKs or things that I don’t want to recreate.

    I could, I mean I use version control and tools to make refactoring easy, but everything is more complex than renaming this column.

    Renames

    In SQL Server, we have an sp_rename function to handle this. I had hoped there was a way with ALTER TABLE ALTER COLUMN, but while I can change types, nulls, etc., I can’t change the name.

    SQL is such a weird language.

    Certainly for SQL Server. PostgreSQL and Oracle have an alter table rename column a to b in the DDL. We have a function. Vote for a cleanup here.

    In any case, the syntax is: sp_rename <objname>, <newname>,<objtype>.

    For me, the code is easy. I qualify out the old name:

    EXEC sp_rename 'dbo.BinaryData.BinaryTexet', 'BinaryText', 'column'

    If I try just the column name, even though this is unique in sys.columns, I get an error. I could do just the table and column like this:

    EXEC sp_rename 'BinaryData.BinaryTexet', 'BinaryText', 'column'

    One really interesting thing is that if I fully qualify things, I definitely don’t get what I want. Be careful here. Another reason why an ALTER TABLE RENAME COLUMN syntax should exist.

    2025-12_0236

    After all my experiments,  I can fix this:

    EXEC sp_rename 'dbo.BinaryData.[dbo.BinaryData.BinaryTexet]', 'BinaryText'

    SQL New Blogger

    This was a short post I made after realizing I made a mistake. I took about 10 minutes to experiment with renames, and another 5 searching to be sure I couldn’t rename things.

    In the experiment, I realized how I could break things, so I captured that mistake (and fixed it), and pointed it out. Showcase how you learn. For bonus points, write a blog where you use AI to help you do this.

  • An SSIS Upgrade

    I came across a post recently on the Microsoft Fabric blog about the evolution of SSIS 2025..I hadn’t heard much about SSIS in SQL Server 2025, so I thought this might provide some info on the investments that Microsoft is still making in Integration Services. I’ve run into a few people in the past year who are still heavily invested in SSIS and run packages daily. SSIS seems to be a technology that isn’t even close to dying for many organizations.

    The blog starts well, delving into the security investments with the change to the SqlClient and TLS 1.3, as well as supporting Strict Encryption. I don’t know many people using this level of security, but it’s good to have SSIS support stronger security. There is also an upgrade for SSIS packages targeting Fabric Data Warehouses if they modify their approach.

    There is also a mention of lift and shift into Fabric Data Factory as an early access program. I wonder how many organizations are looking to still run SSIS packages, but upgrade to Fabric. I’m sure there must be some, and I’m interested if any of you are in this situation. Many of us buy SQL Server licenses, so I would hope Microsoft could invest in a few new SSIS tasks, like SFTP at the least.

    The rest of the post covers Fabric and Azure Data Factory, not SSIS. I understand that Microsoft would prefer everyone abandon SSIS and move to ADF/Fabric, but that’s not what a lot of customers want to do. Many of us have no real need for complexity beyond what SSIS does. What I’d really like to see is a local version of ADF. Many of us still run our own systems and plan to do so for years. If there isn’t going to be an investment in SSIS, which I do understand, then invest in a local version of ADF.

    I doubt Microsoft has much interest in doing work here, especially as the trend towards lakehouses and Parquet files seems to drift further from the idea of SSIS moving data between systems. However, there is still a need for many organizations that might want to build packages to export their data to a data lake on-premises. They might prefer to host their own storage, use Polybase to query those files, and maybe grow into Fabric and Power BI over time.

    Giving options is something Microsoft has often done in the past. Their successes often open the door wider for others to build on their platforms. Their failures are often in places where they try to force everyone to work in a particular way with a particular technology. Expecting everyone to move to ADF/Fabric feels like one of the latter decisions.

    Steve Jones

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

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