Additional Articles


External Article

BIT of a Problem

The BIT data type is an awkward fit for a SQL database. It doesn't have just two values, and it can do unexpected things in expressions. What is worse, it is a flag rather than a predicate, and so its overuse, along with bit masks, is a prime candidate for being listed as a 'SQL Code Smell'. Joe Celko makes the case.

2011-01-24

3,676 reads

External Article

LINQ Lycanthropy: Transformations into LINQ

LINQ is one of the few technologies that you can start to use without a lot of preliminary learning. Also, it lends itself to learning by trying out examples. With Michael Sorens' help, you can watch as your conventional C# code changes to ravenous LINQ before your very eyes.

2011-01-21

3,948 reads

External Article

SQL Server Unit Testing with tSQLt

When one considers the amount of time and effort that Unit Testing consumes for the Database Developer, is surprising how few good SQL Server Test frameworks are around. tSQLt , which is open source and free to use, is one of the frameworks that provide a simple way to populate a table with test data as part of the unit test, and check the results with what should be expected. Sebastian Meine and Dennis Lloyd, who created tSQLt, explain

2011-01-19

3,084 reads

External Article

Making a more reliable and flexible sp_MSforeachdb

While the system procedure sp_MSforeachdb is neither documented nor officially supported, most SQL Server professionals have used it at one time or another. This is typically for ad hoc maintenance tasks, but many people (myself included) have used this type of looping activity in permanent routines. Sadly, I have discovered instances where, under heavy load and/or with a large number of databases, the procedure can actually skip multiple catalogs with no error or warning message. Since this situation is not easily reproducible, and since Microsoft typically has no interest in fixing unsupported objects, this may be happening in your environment right now

2011-01-18

3,580 reads

External Article

Data Conversion in SQL Server

Most of the time, you do not have to worry about implicit conversion in SQL expressions, or when assigning a value to a column. Just occasionally, though, you'll find that data gets truncated, queries run slowly, or comparisons just seem plain wrong. Robert Sheldon explains why you sometimes need to be very careful if you mix data types when manipulating values.

2011-01-12

4,537 reads

External Article

Contiguous Time Periods

It is always more efficient to maintain referential integrity by using constraints rather than triggers. Sometimes it isn't obvious how to do this. Until a recent idea by Alex Kuznetsov, the history table presented problems for checking data that were difficult to solve with constraints. Joe Celko explains.

2011-01-11

3,294 reads

Blogs

In-Person CISA Training – April 13-16, 2026

By

I will be leading an in-person Certified Information Systems Auditor (CISA) exam prep class...

EightKB 2026

By

EightKB is back again for 2026! The biggest online SQL Server internals conference is...

The FinOps Lifecycle: From Budgeting to Reporting

By

Working in DevOps long enough teaches you two universal truths: That’s exactly why I...

Read the latest Blogs

Forums

VS Code, Unresolved References.

By mjdemaris

Hi all, I just started using VS Code to work with DB projects.  I...

Fun with JSON II

By Steve Jones - SSC Editor

Comments posted to this topic are about the item Fun with JSON II

Changing Data Types

By Steve Jones - SSC Editor

Comments posted to this topic are about the item Changing Data Types

Visit the forum

Question of the Day

Fun with JSON II

I have some data in a table:

CREATE TABLE #test_data
(
    id INT PRIMARY KEY,
    name VARCHAR(100),
    birth_date DATE
);

-- Step 2: Insert rows  
INSERT INTO #test_data
VALUES
(1, 'Olivia', '2025-01-05'),
(2, 'Emma', '2025-03-02'),
(3, 'Liam', '2025-11-15'),
(4, 'Noah', '2025-12-22');
If I run this query, how many rows are returned?
SELECT t1.[key] AS row,
       t2.*
FROM OPENJSON(
     (
         SELECT t.* FROM #test_data AS t FOR JSON PATH
     )
             ) t1
    CROSS APPLY OPENJSON(t1.value) t2;

See possible answers