2004-11-18
1,903 reads
2004-11-18
1,903 reads
2004-11-17
2,076 reads
2004-11-15
2,184 reads
2004-11-12
3,085 reads
2004-11-11
2,427 reads
2004-11-10
1,552 reads
2004-11-09
2,229 reads
Another in our series of things you should avoid at all costs. Seems silly at first, not having a detailed recovery plan for your SQL Server. Perhaps it is, but having dealt with any number of problems over the last few years, Steve Jones has some ideas why a detailed plan may not be the best thing to spend your time on.
2004-11-09
8,071 reads
This is the first article by Steve Jones that examines a programming technique for handling operations that may be too large to run in a single query.
2004-11-05 (first published: 2001-05-09)
19,395 reads
2004-11-05
2,388 reads
By Brian Kelley
I will be leading an in-person Certified Information Systems Auditor (CISA) exam prep class...
EightKB is back again for 2026! The biggest online SQL Server internals conference is...
By HeyMo0sh
Working in DevOps long enough teaches you two universal truths: That’s exactly why I...
Comments posted to this topic are about the item Fun with JSON II
Comments posted to this topic are about the item Changing Data Types
Comments posted to this topic are about the item Answering Questions On Dropped Columns
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