Limiting Results with TEXTSIZE in SQL Server: #SQLNewBlogger

There is a SET command in SQL Server that changes how much data is returned from some fields. This short post shows what I learned about the SET TEXTSIZE command.

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

The Scenario

Let’s start with a little code. I actually created a table that looks like this:

CREATE TABLE [dbo].[Beer]
(
[BeerID] [int] NOT NULL IDENTITY(1, 1),
[BeerName] [varchar] (20) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[brewer] [varchar] (20) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[beerdescription] [varchar] (max) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

I added data so that I have something in here:

INSERT INTO dbo.Beer
   (BeerName, brewer, beerdescription)
VALUES
  (1,    'Becks', 'Interbrew', 'Beck''s is a German-style pilsner beer known for its golden color, full-bodied taste, and a crisp, clean finish with floral and fruity hop aromas, brewed according to the German purity law')
,(2,    'Fat Tire', 'New Belgium    Toasty malt, gentle sweetness, flash of fresh hop bitterness. The malt and hops are perfectly balanced.')
,(3,    'Mac n Jacks', 'Mac & Jack''s Brewery', 'This beer erupts with a floral, hoppy taste, followed by a well rounded malty middle, finishing with a nicely organic hop flavor. Locally sourced two row grain and a blend of specialty malts give our amber its rich taste.')
,(4,    'Alaskan Amber', 'Alaskan Brewing', 'Alaskan Brewing Amber Ale is an "alt" style beer, meaning it''s fermented slowly and at colder temperatures, resulting in a well-balanced, richly malty, and long-lasting flavor profile with a clean, pleasing aftertaste.')
,(8,    'Kirin', 'Kirin Brewing', 'Kirin Ichiban is a Lager-type beer, which means it is fermented at low temperatures and offers a light and refreshing texture with a smooth and balanced flavor.')

Now, let’s see what this setting does.

SET TEXTSIZE

This command changes the behavior of SELECT queries and controls how much data is returned in bytes. The setting is the command with an integer after it. The max value is 2GB.

I’ll run a normal query, then I’ll set a smaller size and repeat the query. Notice how the results differ below. I get less data in the second query.

2025-04_0218

What this setting does is limit the number of bytes from some fields. I only have 20 characters from each description.

Let’s do one more query. I’ll lower the value to 5.

2025-04_0219

Note that while the description is very low, the name and brewer are not cut off.

The explanation is that this works on the max types: varchar(max), nvarchar(max), varvinary(max), text, ntext, and image. Non-max fields aren’t affected.

Also note that the default setting from the SQL Native Client and ODBC driver is –1, for unlimited data. That explains why I haven’t noticed this as I’m often using an app that uses one of those. IF you set this to 0, then it defaults to 4KB.

A nice way to prevent apps from grabbing tons of data unless they need it, though you’d certainly need to help users understand why they weren’t getting all the data expected. I think long fields (or image/audio/etc. data) would need a “get more” or “get all” item in software to reset this and return the full value in the table.

SQL New Blogger

This was a function I ran across, whose purpose I had no idea about. I read it, experimented, and in about 30 minutes had put together this demo and post. Easy to do and quick.

I learned something, and I’m sharing this with potential employers. You could as well, with a little effort.

Posted in Blog | Tagged , , | 4 Comments

Using Feature Flags

The use of feature flags in software development has become more and more prevalent over time, especially as teams move to DevOps-style development with frequent releases. I’ve often thought that using feature flags allows technical people to separate out the deployment of some feature or change from the release of that to users. There are a number of articles on this style of work (feature flag driven development, Why Use Feature Flags?) as well as a discussion at Reddit.

I am a big believer in feature flags helping with improving your software in many ways. These articles (and others) highlight the advantages that a software organization gains by using feature flags. Failed releases become less of an issue, as the specific change that doesn’t work can be turned off. This can even work with databases. I can deploy a database change and at a later time have the code (or new table/column) start being used when a feature flag is set. If there is an issue, I can turn off the feature flag and stop using the code (or populating the schema). I can then clean things up, even saving data before I make a change.

I don’t love the idea of using feature flags to handle security access to features, which is pointed out in a few places. If this is for testing or evaluation by customers, perhaps. If this is to get access to data from a security standpoint, this is a bad idea. I hope most of you are savvy enough to realize this.

Feature flags are not a panacea for preventing issues. They do clutter up code and make it harder to read. Once a feature is done and permanently enabled, the code for switching flags should be removed. It is also hard to stack versions of features up behind one flag, which can increase coding mistakes. Adding flags in stored procedures or functions also can wreak havoc on query optimizers, so I’d recommend you don’t do that. Instead handle feature enablement in the application code and use multiple procs/functions for the different functionality you might need.

To use feature flags appropriately with database changes, you also need to be able to dark deploy those changes, with your application code able to handle additive changes to the database. A new column, a new table, or a new parameter should be easy to add without breaking the app code. This requires the use of defaults as well as good coding practices (no select *, inserts with column lists), but it can be done. Once you are in this place, life becomes a lot less stressful and feature flags work amazingly well.

Steve Jones

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

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

Posted in Editorial | Tagged | Comments Off on Using Feature Flags

The Book of Redgate–Being Reasonable

As a part of the Book of Redgate, we have a series of (red, of course) pages with the title “What we believe”. These are our values, as set up by the founders. The first one of these is:

You will be reasonable with us

We will be reasonable with you

Two simple sentences, but they really encapsulate how we try to work together. We know there are stressful times, there are hard times, and while we all want to follow the golden rule (treat others as you would want to be treated), we sometimes fail. However, we try to be reasonable with each other.

If I ask for something, others should try to accommodate me. If I ask for too much, and they tell me that, I should try understand that. Being reasonable is having sound judgment, being fair and sensible, not being extreme.

We try to get along with others. Some good examples of this are us setting normal working hours, but being willing to flex with others. If someone goes above and beyond, we recognize that and perhaps go out of our way to make it up to them.

One example of this stands out in my mind. At our annual company meeting our CEO told a story of a deal that they were trying to close during the year. A crucial part of this deal was one employee, who had scheduled a holiday previously. As the deal was getting close, and in danger of problems, this employee came off vacation to help finish something. Our CEO not only recognized this, but personally thanked them in front of the company, gave them more holiday to make up for it and sent a gift.

We are reasonable with each other, all of us being willing to bend and flex, but not abusing that willingness.

Just like a family does with each other. At least, my family does.

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.

Posted in Blog | Tagged , , | 4 Comments

A Domain for Data

A domain is a set of possible values (among other definitions). I use this word a lot in my work, often with a problem domain (the thing you’re trying to solve) or the domain of possible values (like the US States and Territories list). That last one is interesting, as this is often the set of data we stick in some reference or lookup table to use in a form on a screen.

There is a domain as part of the SQL specification, which I never knew about. I was reading an article from Joe Celko on the CREATE DOMAIN statement. This doesn’t exist in SQL Server and T-SQL, but it has been a part of PostgreSQL for quite a few versions. The article talks about the definition of a domain from a few very experienced database design people.

What’s interesting is that this could be a list of values, but it could be an expression against which values are checked. For example, we might choose the domain of positive integers, which might require that the value passes some x>=0 where x is the value. That seems OK, though this looks like a CHECK constraint to me, which we already have.

The article is a little light and doesn’t give many examples of how or why a domain might be needed or why it might be better than a constraint. Perhaps there are good reasons, but I struggle to think of any. Certainly I am cautious of tightly binding which data is allowed, especially when I find many businesses have rules that often have exceptions.

Would you use a domain for any data in your system? Do you think you have business rules that are firm and set enough to add domains? Perhaps you do, and if you do, that’s great. I suspect many of you are like me in that you are careful of where and how many check constraints you use. Those can be very hard to change and remove when an exception occurs, so the fewer the better.

Steve Jones

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

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

Posted in Editorial | Tagged | Comments Off on A Domain for Data