Has Everyone Had a Data Breach?

Almost every time that I attend an event, I’ll end up meeting someone that has had security issues at their company. I’m always surprised how many people have had ransomware or other security problem that didn’t get well publicized. It’s not like everyone has had one, but out of 100 people, it seems there is at least one issue.

Many of us work with third-party companies for either products or services. It’s become standard to use other firms for specific things your organization needs. However, since that’s the practice, many of those firms you partner with have their own partners. After all, they’re using other companies for specialized work just like you are.

These third- and fourth-party relationships have changed our security and risk profiles for the worse. As the numbers of data breaches and security issues grow, it’s likely that someone in your partner network has had an issue, which might mean that you have an issue. This depends on what you have contracted with partners for, but it seems more and more often this is some sort of service provided, often with your data being shared with the partner. Which could mean your data is shared with their partners.

An article recently noted that the number of partners are going up and many organizations are not aware of the risk this creates for them and their customers. There are more and more third- and fourth-party partners who have suffered data breaches, and if they have shared our data, we may have liability. The weakest link in a supply chain is the problem, and many of us have lengthened our supply chains quite a bit without paying attention.

I don’t know that there are good solutions here, but I am seeing more and more companies demanding that suppliers of services prove they have strong security practices and protocols in place. It’s not perfect, but it does help us remember that security is everyone’s business, or at least everyone with whom we share our data.

Steve Jones

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

Posted in Editorial | Tagged | 1 Comment

Daily Coping 8 Mar 2023

Today’s coping tip is ask someone how their day is going and really listen to them.

I had the chance to do this with one of the kids I coach recently. This athlete seemed a little distracted and annoyed by things, without great body language one day. It wasn’t busy, so I asked a few questions, wanting to know about this person, what was good, bad, what went well, not well, what was bothering them.

Not a deep discussion, but one where I could listen to them, express sympathies, but not solve their issues.

I enjoy getting to know someone I care about better, even when I can’t do anything for them at the moment.

I started to add a daily coping tip to the SQL Server Central newsletter and to the Community Circle, which is helping me deal with the issues in the world. I’m adding my responses for each day here. All my coping tips are under this tag.

Posted in Blog | Tagged , , | Comments Off on Daily Coping 8 Mar 2023

Daily Coping 7 Mar 2023

Today’s coping tip is give positive comments to as many people as possible today.

On a travel day, I made an effort here. Those are always better for me, when I see a lot of people and can brighten their days.

  • Thanking the bus driver at the airport
  • Greeting the cashier at my favorite restaurant kindly
  • Complementing the flight attendants on their look and service
  • Chatting with the Uber driver and expressing gratitude for recommendations
  • Taking a few minutes with the hotel receptionist
  • Being positive and thanking a waiter at a restaurant

I started to add a daily coping tip to the SQL Server Central newsletter and to the Community Circle, which is helping me deal with the issues in the world. I’m adding my responses for each day here. All my coping tips are under this tag.

Posted in Uncategorized | Tagged , , | Comments Off on Daily Coping 7 Mar 2023

Nested Transactions

One of the very common expectations from many SQL developers involves transactions. Many developers (database or application developers) think they can open a transaction, do something, open an inner transaction (nested), and then commit or rollback the inner transaction separate from the outer one.

If you’ve worked with explicit transactions and experimented with this a bit, then you know that this doesn’t work. Recently Brent Ozar wrote a post on this as he had a client think that committing the inner transaction would release locks. It doesn’t.

Knowing whether work gets committed or not is important to data integrity. We often need to ensure that multiple things happen or nothing happens. That’s key, and if we want to decide that thing A can happen without thing B, those are two transactions. In most cases, where we’d want the behavior I described at the top, these don’t need to be nested. They’re just two transactions.

Understanding how data modifications work is important, especially if you work across different platforms and you need to ensure there is some level of durability. Some platforms use different locking strategies, some limit transactions even more, and digging into the details is important.

As technical people, we know there are many ways to solve problems, and we often spend a lot of time ensuring that users of our systems have options. We would assume our users will learn and understand how the options work, which is no different that what we ought to do ourselves. Don’t assume. Ensure you know how the database will behave if you depend on it behaving a certain way.

Steve Jones

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

Posted in Editorial | Tagged | Comments Off on Nested Transactions