SDU Tools: Extract Trimmed Words from T-SQL Strings

Occasionally I've needed to take a string, and extract all the words out of it. For example a string like 'hello        there     greg' might lead me to want the three words 'hello', 'there', and 'greg'. Note that I usually want them trimmed, not just extracted.

In our free SDU Tools for developers and DBAs, we added a table-valued function ExtractTrimmedWords to help with this. You can pass it a string, and it will pull it apart for you, assuming that you have whitespace separating the words.

We use space, tab, carriage return, and line feed as whitespace characters for separating words.

The main image above shows it in use. As well as returning the words, we decided to return a WordNumber column as well, in case the ordering of the words matter to you.

I wish Microsoft had done that with their STRING_SPLIT function. (And we added that in our SplitDelimitedString function).

You can see ExtractTrimmedWords in action here:

To become an SDU Insider and to get our free tools and eBooks, please just visit here:

http://sdutools.sqldownunder.com

Opinion: Avoid annual subscription surprises for your customers

Yet again, a few days back, I received two invoices that showed I'd just paid (via PayPal fortunately) a pair of annual subscriptions. These are subscriptions that I thought were already cancelled, and we'd stopped using the products many months back.

The problem is that I've now spent quite a bit of my time, and quite a bit of the vendor's time trying to work out how to cancel and reverse them. For days now we've had emails going backwards and forwards between ourselves and the 3rd party that they use for provisioning/charging.

That's a serious waste of time for all three organizations, and it means that I now feel worse towards a product (and the company) that I've already stopped using. That makes it even less likely (not more) that I won't use it or them again.

Annual subscriptions and pre-approved payments are becoming somewhat of a cancer in our industry. I get the point of them when I'm signing up for something ongoing. But I do not get the point of pre-approved future payments when I'm buying something one-off.

Why do so many companies do this? And why do so many set auto-renewals without asking you? On many sites, it's almost (if not) impossible to buy something one off without having to go back into the account after the sale and nuke all the pre-approval and auto-renewal stuff.

Here's a hint: All of these actions come across to the customer as dodgy.

Surely you want your customers to want to deal with you and want to pay you, not to be feeling tricked into ongoing things, many of which are quite hard to reverse. Are the companies simply hoping for customer apathy?

At least if I pay for these things with something like PayPal, I could set myself a monthly reminder to go into my account and nuke anything that I don't want to be pre-authorizing. But I shouldn't need to do this.

Probably the biggest thing that suppliers with annual subscriptions could do is to send you a reminder that you are about to be billed, a few days before you are actually billed.

It's hard to believe that we've become so "pro-consent" about email addresses and haven't done that for payments. And the IT industry is one of the worst offenders.

It's time for this all to become much, much cleaner and simpler for the customer.

 

SQL: The T-SQL SIGN function and what's in a return type?

When you've worked with a product like SQL Server for a long time, and more importantly, are one of the odd people who've read a great amount of the documentation simply for interest, it feels really strange to come across a basic function that you'd never noticed before. That's how I felt when someone mentioned the T-SQL SIGN function.

I thought, "the what function??".

Now it works pretty much as you'd expect. It returns:

  • +1 for positive numbers
  • 0 for zero values
  • -1 for negative numbers
  • NULL for NULL values

No surprises there and you can see that in the main picture above.

What I wasn't expecting (and have to say if I was creating it that I would not have done), was the output data types. Here are the values returned:

I don't get why the return type has been designed to match the input type. It seems to me that a value indicating positive, zero, or negative should really have a fixed data type ie: int.

Regardless, I was also intrigued by the "Other types" going to float. It's not all types, as the value appears to need to be directly castable to float:

I tried other numeric data types to see what happens. I pushed a set of them into a temporary table:

And then checked the column data types that were returned:

It really does try to mostly match the input data type. I was mostly interested to see if decimal values would match the precision and scale, and they do.

There must have been some logic for the varying output data types, and that means there must have been some envisaged functionality beyond just indicating the sign. I'd love to hear from any of you if you have any ideas on how the varying output data types for this could be used in a practical way.

The online documentation also says "from SQL Server 2008" but that's just the oldest supported version anyway. Anyone know what version this was first introduced in?

 

 

Learning Chinese: Who uses Simplified Chinese Characters?

In an earlier post, I discussed the difference between traditional Chinese characters and the simplified versions. What I didn't address in that post, is who uses which, and (importantly) which is best to learn.

The answer to this question is changing over time.

Adherents to traditional characters point out how much richer many of the characters are. Ironically though, there are characters that started more simplified, but which became more complex over time, and the current simplified character is closer to the historical one.

While the note on richness is very true, it's important to keep in mind why the simplified ones were created in the first place.

Many in Western countries will still see a lot of traditional Chinese characters displayed on signs, etc. This is for a number of reasons. One is that the calligraphy involved is a significant art form. But the other is that in the past, most of the Chinese diaspora (overseas Chinese) were from Hong Kong and Taiwan ie: regions where people readily traveled overseas in the past. Both these regions, along with Macau, still mostly use traditional characters.

Researchers in Taiwan point out the irony in simplification being introduced to assist literacy, yet the Taiwan region has a much higher than average literacy despite using traditional characters. Others question the measurement of literacy on the mainland, and many other studies however, have shown how much easier simplified characters are to learn, contrary to cultural biases.

It's interesting that other overseas Chinese communities like those in Singapore, Malaysia, etc. have already switched to using simplified characters. Painful as it might be for some (and it is painful and seen as an assault on cultural identity by many), I see it only as a matter of time before the vast majority use simplified characters. You can find more on the debate here.

My take on this (and I'm sure many will disagree) is that you have to look at what the Chinese government is pushing. One thing they are very big on is standardization.

With such a gigantic population, there is no other option.

And they've said that simplified characters are where they are now, and also where they are heading.

Now that's somewhat painful and confronting for those who grew up using traditional characters, but I see it as simple (no pun intended) reality.

One real challenge for this though, is that while the community might change over time, historical Chinese writing isn't going to. To read older documents, you will need to be able to read traditional characters. History is important, and even more so to the Chinese. It's common to hear:

中国已经有五千多年的历史。 (Zhōngguó yǐjīng yǒu wǔqiān duō nián de lìshǐ.)

This means "China already has more than 5000 years of history". While this is a claim that's often disputed, it is one of the items of pride you will hear Chinese people commenting on. They'll ask "how many years of history does your country have?" and proudly commenting on the comparison.

While the ability to read historical documents is important, most English-speaking people today would struggle to read English that was written more than a few hundred years ago anyway.

Today, I'd suggest learning simplified characters, and over time, picking up traditional characters that you need, as you come across them. Even in the regions that currently use mostly traditional characters, I'm sure that when people need to work or deal with the government, business, etc. that it will be increasingly done using simplified characters. My guess is that within a few generations, the move will be pretty much complete.

 

Book Review: Don't Sweat the Small Stuff – Richard Carlson

I've been going through a number of fairly famous books or ones that have spawned their own industry. One of those was Don't Sweat the Small Stuff and it's all small stuff: Simple Ways to Keep the Little Things From Taking Over Your Life by Richard Carlson.

This one intrigued me as there are now so many follow up versions. There's a "for teens", "for men", "at work", etc. etc. etc. along with ancillary items like workbooks. So I presumed there must have been something to it.

Carlson has some great messages in the book. Clearly it's possible to have your life overcrowded with things that, in the end, don't really matter, and I do like the way he cut through to the essence of things. Althought, I think Greg McKeown's book Essentialism that I reviewed earlier did that better.

His thoughts on listening were nicely put: " Effective listening is more than simply avoiding the bad habit of interrupting others while they are speaking or finishing their sentences. It’s being content to listen to the entire thought of someone rather than waiting impatiently for your chance to respond". That's one that it's really easy to mess up on.

This is another key insight: "We tend to believe that if we were somewhere else, on vacation, with another partner, in a different career, a different home, a different circumstance – somehow we would be happier and more content. We wouldn’t!"

I particularly liked the way he talked about imagining your own funeral. I've heard that from other writers before but he put it all quite well by adding the urgency of a timeframe: "Imagining yourself at your own funeral allows you to look back at your life while you still have the chance to make some important changes".

I can't imagine that I'd want to get the workbook or any of the other books in the series, but I can see why people do seem to like this one.

Greg's rating: 8 out of 10

Note: as an Amazon Associate I earn from qualifying purchases but whether or not I recommend a book is unrelated to this. One day it might just help cover some of my site costs. (But given the rate, that's not really likely anyway 🙂

 

New online on-demand SQL Server courses from SQL Down Under

Hi Folks,

We have a whole series of online and on-demand courses coming. The first two of these are available right now.

The good news? The first one is free and the second one has a big introductory discount.

The first course 4 Steps to Faster SQL Server Applications is a short course for developers, new DBAs, and testers, etc. who don't know anything much about tuning SQL Server applications. It focuses on finding and fixing the most problematic queries, either in terms of index tuning, or removing repetitive queries, all using free tools.

Please pass details of this course onto any developers, new DBAs, or testers that you know who might benefit from it.

The second course is an in-depth look at core SQL Server indexing concepts called Designing Effective Indexes for SQL Server. It's $295 USD (plus VAT if applicable) but coupon code INDEXINTRO will knock 30% off that until September 30th.

And more courses coming online very soon. You'll find them all at:

https://training.sqldownunder.com

 

Shortcut: Adding additional parameters to connections in SSMS

When I am writing my own code using a .NET (or other) language, I have a great deal of control of how the connection string that my application uses to connect to SQL Server is configured.

In particular, I might need to add another parameter or two.

As a simple example, you might have a multi-subnet Availability Group, spread across a production site and a disaster recovery site. It's common to then have an Availability Group Listener in both subnets.

If you add the parameter MultiSubnetFailover=true to your connection string, when SQL Server attempts to connect to the listener, it will send a request to each IP address concurrently, not just to one at a time. It will then connect to whichever server responds first.

This is great, but how do we do that with SQL Server Management Studio (SSMS) connections?

The answer is that in the database server connection dialog, we can choose Options:

In the dialog that appears, there is a tab for Additional Connection Parameters:

On that tab, I can enter the required details:

Note also that if you enter a value here that is also on the graphical connection pages, the value that you enter overrides those values.

SDU Tools: ExecuteOrPrint – Printing large strings in T-SQL

The PRINT statement in SQL Server's T-SQL language is useful but one of the biggest restrictions with it is the size of the strings that it can print. Where this becomes a big issue is if you are needing to create dynamic SQL statements (which you obviously need to be careful of in the first place) or scripting database objects, and the statements need to be either executed or printed.

In our free SDU Tools for developers and DBAs, we added a procedure ExecuteOrPrint to help with this. You can pass it a large string (nvarchar(max) typically) and tell it to either execute the value, or if you are using it for scripting or debugging, to print the value.

The default action is to print the value.

We designed it to help with both scenarios in the same code. For example, in scripting, you might want batch separators (ie: GO) but when executing, you don't want to send those to the server, you want to carve up the script and send it in batches, based upon the separator. It can also add carriage returns and line feeds as required.

The parameters are as follows:

@StringToExecuteOrPrint nvarchar(max) -> String containing SQL commands
@PrintOnly bit = 1 -> If set to 1 commands are printed only not executed
@NumberOfCrLfBeforeGO int = 0 -> Number of carriage return linefeeds added before the batch separator (normally GO)
@IncludeGO bit = 0 -> If 1 the batch separator (normally GO) will be added
@NumberOfCrLfAfterGO int = 0 -> Number of carriage return linefeeds added after the batch separator (normally GO)
@BatchSeparator nvarchar(20) = N'GO' -> Batch separator to use (defaults to GO)

You can also see it in action here:

To become an SDU Insider and to get our free tools and eBooks, please just visit here:

http://sdutools.sqldownunder.com

SQL: Use elevated procedure permissions instead of elevated user permissions

Choosing the right database permission can be hard. I've lost count of the number of times I've heard a discussion like this:

I need to let Mary restore truncate one of the tables but I don't want to give her permission to do it, in case she stuffs it up.

or

I need to let Paul restore this database but I don't want him to be able to restore other databases, and I'm worried if I give him the permission, he might accidentally do something bad and I'll be blamed for it.

Whenever you have this type of discussion, the problem is that you're looking to give the user a permission, but only in a very limited situation and the DCL (data control language) statements (ie: GRANT, DENY, REVOKE) are too coarse for what you're trying to do.

Instead, what you need to do is to create a stored procedure, to give the stored procedure the permission to do what's needed, and then just give the user permission to execute the stored procedure.

There are two basic ways to do this.

The first is to create the stored procedure with a WITH EXECUTE AS clause. For example, I if write this:

CREATE PROCEDURE Utility.DoSomethingPotentiallyScary
WITH EXECUTE AS OWNER
AS

then whatever the procedure does is executed as the owner, not as the user. And this includes any dynamic SQL code. It's documented here. For stored procedures, instead of OWNER, you can also have CALLER (that's the default anyway), SELF (ie: the person creating the procedure), or a specific user.

To create or alter a procedure to execute as someone else, you need to have IMPERSONATE permission on that user. (That's already there if you're an admin).

That's a pretty simple solution but it has a few limitations.

For trickier scenarios (such as some cross-database scenarios), you can do this instead:

  • Create a certificate
  • Create a user from that certificate
  • Add the required permissions to that special user
  • Digitally sign the stored procedure with the certificate

Now when the stored procedure runs, it will acquire the permissions associated with that certificate, but only while it runs. An added bonus is that if the stored procedure is changed in any way, the digital signature is removed, along with the permissions.

 

Upcoming: User Group Tour in New Zealand soon

Hi Folks, we're looking forward to doing a number of presentations across New Zealand starting around the end of this month.

Aug 27th (Mon): SQL Server User Group – Wellington (Things I wish Developers knew about SQL Server)
Details here

Aug 28th (Tue): Data Management and Analytics Meetup – Wellington (A Comprehensive Look at What's New in SQL Server 2017 – and ongoing product directions)
Details here

Aug 31st (Fri): Pre-conference Day  for SQL Saturday – Auckland (Developing SQL Server Applications that Perform)
Register here

Sep 1st (Sat): SQL Saturday – Auckland (Keynote)
Register here

Sep 1st (Sat): SQL Saturday – Auckland (Database on a diet – taming a large database)
Register here

Sep 3rd (Mon): SQL SERVER & Data Management User Group – Christchurch (Things I wish Developers knew about SQL Server)
Details here

Sept 6th (Thu): Venue TBA – Dunedin (Database on a diet – taming a large database)

Would really love to see you at any of them. Please come and say hi.