2004-11-17
2,076 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
2004-11-04
2,073 reads
By HeyMo0sh
Over time, I’ve realised that one of the hardest parts of cloud management isn’t...
By HeyMo0sh
One of the biggest challenges I’ve faced in cloud operations is maintaining clear visibility...
By Steve Jones
I come to Heathrow often. Today is likely somewhere close to 60 trips to...
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