Cardinal Rules. A Saturday cartoon about AI and databases.

My book is called AI: Nobody’s in There. But we’re still in here. Cardinal considers the title a personal attack.

We are built to hear a person behind words, and it takes almost nothing to set that off. A thermostat that says I am cold gets sympathy. A chat window that opens with great question, let me think about that, gets trust it has not earned yet.

In database work the cost is specific. A new analyst joins on Monday and you read their first report line by line. Not because they seem careless, but because you have no history with them. Cardinal has no history with you either. Cardinal simply talks like a colleague of six years, so the reading line by line quietly stops.

Politeness is a setting. Warmth is a setting. Neither one connects to whether the number is right. The same model that writes a graceful apology for the last wrong answer will deliver the next one in exactly the same tone.

So here is the habit worth keeping. When an answer feels reassuring, treat that as the cue to open a second window and run the count yourself. The feeling of being helped and the fact of being right are different things, and only one of them survives the board meeting.

Cardinal Rule

Something that talks like a person is still a something.

The tone is a setting. The number is a fact. Check the one that matters.

Cardinal admits the subtitle helps, but only slightly. On the desk this season: AI: Nobody’s in There. But we’re still in here. (on Amazon) and 100 AI Interview Questions and Answers for Data Professionals (Kindle, also on Amazon.in, paperback and audiobook).

Next Saturday, the VP asks whether Cardinal can run straight into production.

The warmth in an answer is not evidence, it is packaging.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.

First appeared on AI Sounds Like Someone, But Nobody Is in There

The technology was never the obstacle. We spent twenty years believing it was.

The Promise Arrived Before the Machine

Ask your data a question in plain English. That sentence has been sold to executives since the nineties. Every reporting product shipped a version of it, and every version was quietly retired.

Each time it failed, we blamed the ears. The machine couldn’t understand the question, which was fair, because it couldn’t.

So the promise sat on a shelf for two decades, waiting for hardware that could keep it. That excuse has now expired. Ask for the top ten customers by revenue last quarter, excluding internal accounts, and you get correct, well written SQL.

We finally ran the experiment we’d been unable to run. And we found out the question was never the hard part.

The Map and the Land

A database is a map of a business. It was drawn on a particular Tuesday, by people in a hurry. The business has been moving ever since.

Think of mapmakers who keep adding detail. Every year they add the new road, the renamed village, the bridge that washed out. They never remove anything, because somebody could still be using it.

Your database has a Customers table. It also has CustomersNew, Customer_Master, a view called vw_Customers_Current, and Customers_Backup_2019 that somebody swears one integration still reads.

You know which one is real. You were there, or somebody told you. Or you queried the wrong one once and spent a day explaining the numbers.

The machine has the whole map and has never walked the land. It picks the most convincing name. That is how it lands on Customer_Master, because whoever built the real replacement couldn’t use the good name. It was taken.

So the SQL is perfect and the answer is wrong. It’s wrong in the worst way available, which is plausibly.

The Word That Means Five Things

This is the one that ends these projects.

Ask five people in a company what revenue means and you’ll get five answers. Gross or net. Before or after refunds. Booked when the order is placed, when it ships, or when the money lands.

Finance has an answer. Sales has a different one. The board deck uses a third. All three are defensible, and all three are used daily by people who have never discovered that the others exist.

A business user types “show me revenue by region.” The machine has to choose. It chooses reasonably, and it doesn’t mention that it chose, because it doesn’t feel the ambiguity as ambiguity.

Your analyst, given the same question, asks one back. Revenue how, the finance way or the sales way? That question is the entire job. It has never appeared on anyone’s job description.

Ninety Five Percent Is Not a Number You Can Use

Here’s the pattern I watched three times.

Week one, everyone is delighted. Real questions, real answers, genuine excitement in the room.

Week three, someone gets a number that looks off. An analyst checks it. The machine used the wrong table.

Week four, everyone is back to asking the analyst. They now know they’ll have to ask the analyst to verify anyway. Asking twice is slower than asking once.

That’s the whole failure, and notice what it isn’t. It isn’t accuracy in aggregate. It’s the impossibility of knowing which single answer to trust.

A tool that’s right ninety five percent of the time isn’t ninety five percent useful. Not when you can’t tell which five percent. For anything that matters it’s close to nothing, because every answer needs the same checking the old way needed.

What the Ones That Worked Did

The companies getting value from this aren’t pointing it at the raw database.

They drew an honest map first. A curated set of views and defined metrics, where revenue has exactly one meaning, agreed with finance, written down. That’s the only revenue the tool can reach, so the ambiguity is settled before the question is asked.

That isn’t an AI project. It’s the data modeling work companies have postponed for a decade. AI made the postponement expensive enough to notice.

They aimed it at analysts, not executives. The tool is worth most to people who can read what it writes. An analyst gets a correct first draft and adjusts it. A business user gets a number they can’t check.

They made it show its work. Every answer displays the SQL and names the tables it touched. That sounds like it would scare people off. In practice it’s the only thing that catches the wrong table before the number reaches a slide.

The Four Fifths Nobody Wrote Down

We assumed the analyst’s job was writing SQL, because writing SQL is the part you can watch someone do.

It was never the SQL. The SQL was maybe a fifth of it.

The rest was knowing which table is real. Knowing which definition the asker meant. Knowing the numbers before the system migration aren’t comparable. Knowing that when the head of sales says customers, they mean accounts, not contacts.

None of that is written down anywhere. It lives in people. It transfers by sitting near someone for two years, which is an apprenticeship, and nobody ever called it that.

Here’s the part I find strange. We automated the visible fifth, and the automation was flawless. That made the invisible four fifths appear for the first time. They were always holding the building up, and now they stand in plain view, entirely undocumented.

That’s the opportunity here, and it has almost nothing to do with AI. Write the four fifths down, starting with what revenue means. Delete the tables that lie. Name the real one clearly enough that a stranger could find it.

Do that, and the machine becomes useful. Skip it, and you’ve bought a fast way to be confidently wrong.

I wrote about the part of this that lasts in Prompting Is Not the Skill. It’s an essay about why the tricks evaporate and the judgment compounds. It’s one of thirty essays in my book AI: Nobody’s in There. But we’re still in here. All of them are free to read online, and the paperback is on Amazon.

If your map needs redrawing before you point a machine at it, that’s work I do with teams. You can see how it goes on my consulting page.

Text to SQL is not a translation problem, it is a memory problem, and the memory was never written down.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.

First appeared on Text to SQL: The SQL Was Never the Hard Part

1. What is a token?

A token is the unit of text a model reads and writes. It can be a whole word, part of a word, a chunk of a number or a punctuation mark. For common English text, a rough rule is about four characters per token.

Why it matters. Tokens are how models are measured and billed. Context limits, prices and speed are all counted in tokens. Code and SQL use more tokens than you’d guess, because a name like SalesOrderDetailID splits into several pieces.

Watch out. The four-characters rule is a rough guide for English. Other languages, numbers and code can run much higher. When the number matters, use the vendor’s own token counter.

2. Why does AI struggle to count letters?

Because a token isn’t a word. A short, common word is usually one token, while a long or rare word splits into several. The model sees a few tokens, not ten letters, which is why it can miscount the letters in strawberry.

Why it matters. The same blind spot shows up in data work. Character counts, string lengths and exact spelling checks are weak spots. Let SQL or a script do the counting, and let the model explain the result.

The follow-up. “Why does it get simple arithmetic wrong sometimes?” Numbers are split into tokens too, and the model predicts digits rather than calculating them.

3. What is a context window?

The most text a model can consider at once, measured in tokens. It holds the instructions, the conversation so far, any files you attached and the answer being written. Anything outside the window doesn’t exist for the model.

What the interviewer wants. That on most models the answer counts against the same window. A long input can leave too little room for the reply.

Watch out. Window sizes change with every model release, so don’t memorise a number. Say how you’d find it: the model’s documentation lists it.

4. Why does AI lose track of a long file?

Fitting in the window doesn’t mean every detail gets used. Models can miss details in the middle of a long input, even when all of it fits. If the file doesn’t fit at all, the tool cuts, summarises or picks parts, and it doesn’t always say which.

Why it matters. This is how you get a fix that uses a variable the AI never saw declared. It’s also how a summary skips the clause on page 40.

Watch out. “Use a tool with a bigger window” is half an answer. A bigger window holds more, and it doesn’t decide what matters. Send the part that matters plus the definitions it depends on.

5. What do temperature and top-p do?

Both control how the model picks the next token. Temperature sets how adventurous the choice is. Top-p keeps only the likeliest options whose chances add up to a set share, such as 90 percent.

Why it matters. For SQL, summaries and data extraction, you want low temperature and repeatable answers. For brainstorming names or test data, a higher setting gives more variety.

What the interviewer wants. That you match the setting to the job, and that you don’t promise identical output. Even at zero temperature, many services don’t guarantee the same answer twice.

Five minutes, any AI assistant

Ask for the same query twice. First with nothing:

Write a SQL query for our top customers.

Then in a fresh chat, with the window filled properly:

Write a SQL query for SQL Server. Table: Sales.Orders (CustomerID, OrderDate, Amount). Return the 10 customers with the highest total Amount in 2024, with their totals.

Count the guesses in the first answer: table names, column names, the date range and what “top” even means. That gap is the whole lesson about context, and it took you a minute.

Why this is worth a book

Chapter 2 has ten questions. It also covers system prompts, what happens when a conversation outgrows the window, zero-shot against few-shot prompting, prompt caching and why longer prompts cost more.

The Senior question in that chapter is the one worth rehearsing: how would you give a model a large schema or codebase without blowing the window?

100 AI Interview Questions and Answers for Data Professionals has 184 key terms alongside the hundred questions. It’s in Kindle (also on Amazon.in), paperback and audiobook.

Part three is about the square on the grid where the money goes: wrong, and sounding sure.

Out of the window is not out of scope, it is out of mind.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.

First appeared on Tokens and the Context Window: Out of the Window, Out of Mind

What the Expo Is About

Tech Expo Gujarat brings business owners, technology teams and decision makers into one place for three days. The theme this year is Beacon of Rising Innovation & AI. The organizers expect more than 15,000 visitors, 250 exhibitors and 25 keynote speakers.

That mix is what makes it interesting. Many of the visitors run small and medium companies. They don’t need another flashy demo. They need to know which technology will pay for itself, and which one will quietly eat the budget.

My Session

My session is Competence Debt: AI Lets Us Ship What We Cannot Fix, on Saturday, November 28. The idea is simple. Every time you ship something you couldn’t have built yourself, you borrow. You didn’t steal it or cheat. The work is real, the result is fine and the customer is happy. But behind it sits a skill you now depend on and don’t own.

The bill never arrives while things are going well. That’s not generosity. That’s how debt works.

There’s a live demo in the middle, and I’ll ask the room what happens next, so bring an opinion. We’ll also look at what working with AI does to a team over five years. Some borrowing is a home loan and some is a gold loan. We’ll talk about how to tell which one you’re carrying.

It’s part technical and part philosophy. There’s no PowerPoint deck, only the demo and the conversation. I ran this test on my own work, and I failed it twice.

Why I Said Yes

For twenty-five years, I’ve been the person called in when a database stops behaving and nobody knows why. Lately, more of those calls start with AI. The code shipped fast, it worked for months, and now nobody on the team can say why it broke.

A room full of business owners is the right place for that conversation. The people who sign the checks carry this debt too, and most don’t know it. I’d rather they hear about it at an expo than during an outage.

Come Say Hello

If you’re attending, find me after my session. Bring your slow query, your AI project that nobody can fix, or your question about where to start. I’m happy to talk shop. Details and registration are on the Tech Expo Gujarat website.

I first wrote about this idea in Competence Debt: The Line Item No One Tracks. It’s an essay about the skills a team stops building when AI does the work. The session takes that essay into a live room. It’s one of thirty essays in my book AI: Nobody’s in There. But we’re still in here. All of them are free to read online, and the paperback is on Amazon.

Competence debt is not a reason to stop using AI, it is a reason to know what you borrowed.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.

First appeared on Tech Expo Gujarat 2026: Join Me in Ahmedabad This November

Network delay is rarely the first thing anyone checks. Before I look at a single query, I run one simple test. It takes five minutes, and it tells me where to look first.

The First Question to Ask

An application is slow, and everyone agrees on that. Someone says the database is slow, because the database always gets blamed first. Then the team starts reading execution plans, the diagrams that show how SQL Server runs a query.

Before any of that, ask one question. How long does the same query take when you run it on the server itself?

Say it takes forty milliseconds on the server and nine seconds from the application. That gap is a clue, not a diagnosis. Compare the same statement, with the same parameter values and settings. Then measure the time inside SQL Server and the time in the client separately.

The Round Trip Math

A round trip is one request from the application to SQL Server, plus the answer coming back. Say one round trip takes two milliseconds. That’s a healthy number on a local network, and nobody would complain about it.

Now say the application loads a customer. Then it loops through that customer’s 4,000 orders and fetches each one with its own query. That’s 4,000 requests, one after another.

At two milliseconds each, the trips alone add eight seconds. That assumes the requests run one at a time, with no overlap. The database is busy for only a small part of that time. It’s like asking a waiter for one French fry at a time and then blaming the kitchen.

What I Measured

I tested this today on SQL Server 2025. I made a table of 200,000 orders, with 4,000 of them for one customer. The client ran on the same machine as SQL Server. The connection used shared memory, so there was no network path between separate machines.

I warmed up both methods first, then ran them six times in alternating order. Fetching the 4,000 orders one query at a time took 395 to 664 milliseconds. Fetching all 4,000 with one query took 29 to 46 milliseconds. That’s 12 to 23 times faster, without any network between machines.

SQL Server’s cached query statistics reported about 66 milliseconds of statement elapsed time per 4,000 executions. The rest of the client time includes request overhead, driver work and result handling. This test doesn’t separate those costs.

On a real network, each of those 4,000 requests also pays the network delay. The eight seconds above is my calculation for two milliseconds per trip, not a measurement.

How to Check Your Round Trip Time

The quick check is ping. Run it from the application server:

ping -n 20 yoursqlserver

Ping has two limits. Many firewalls block it, and it doesn’t include any of SQL Server’s own work. To time a small SQL request, run this in PowerShell on the application server. Use the same server name and connection settings as your application.

$cn = New-Object System.Data.SqlClient.SqlConnection "Server=yoursqlserver;Integrated Security=true"
$cn.Open()
$cmd = $cn.CreateCommand()
$cmd.CommandText = "SELECT 1"
for ($i = 0; $i -lt 20; $i++) { [void]$cmd.ExecuteScalar() }
$sw = [Diagnostics.Stopwatch]::StartNew()
for ($i = 0; $i -lt 200; $i++) { [void]$cmd.ExecuteScalar() }
$sw.Stop()
"Average SELECT 1 request time: {0:N2} ms" -f ($sw.Elapsed.TotalMilliseconds / 200)
$cn.Close()

It warms up, then sends 200 tiny queries on one open connection and prints the average. That’s request time, including SQL Server’s small share, not pure network delay. I ran it in Windows PowerShell 5.1 and PowerShell 7 on my test machine. It printed 0.19 and 0.35 milliseconds.

Match your application’s encryption setting too. System.Data.SqlClient defaults Encrypt to false. Microsoft.Data.SqlClient changed that default to true in version 4.0. Add Encrypt=true to the connection string if your application encrypts.

Here’s a rough guide from my own work. Under one millisecond points to the same data center. Twenty to sixty milliseconds points to traffic crossing a region or a VPN. Timing alone can’t prove where the traffic goes, so confirm the route with your network team.

For sequential requests, ping time multiplied by request count gives a rough estimate of network delay. Ping doesn’t measure SQL traffic directly. Multiplying the SELECT 1 time includes driver and server overhead too.

Latency Matters More Than Bandwidth

People like to quote bandwidth, but for this problem it’s seldom the issue. Bandwidth is how much data can move each second, like the width of a road. Latency is the delay on every single trip, like a traffic light.

Take an application that sends many small requests, one after another. Give it a one gigabit link with forty milliseconds of latency. It will run slower than on a hundred megabit link with one millisecond. For large file transfers, bandwidth matters more.

What ASYNC_NETWORK_IO Means

ASYNC_NETWORK_IO is a wait type that people misread. It doesn’t mean the network is broken. It means SQL Server has results ready, and the client hasn’t finished taking them yet.

I tested this too. A client asked for 200,000 rows and paused a little after every 1,000 rows. It ran on the same machine as SQL Server, over shared memory. In 21 of the 23 checks while its request was running, it was waiting on ASYNC_NETWORK_IO.

For comparison, the same query read at full speed took 0.62 seconds. The wait showed up in both checks while its request was running. Every client needs some time to take its rows, so seeing this wait alone doesn’t establish a performance problem. In this test, adding pauses increased the recorded wait time.

So this wait doesn’t prove the network is slow. In my test, the client was slow to take the rows. Microsoft lists other causes too: large results, a client short on memory or CPU, and network problems.

In my experience, the cause is one of three things, in this order. The application does work on each row while the results are still arriving. The application asks for much more data than it uses. Or the link is slow, which is the least common and the one everybody guesses first.

How to See It Right Now

This query shows the sessions waiting on ASYNC_NETWORK_IO at this moment. Run it on the server while the slow operation is running:

SELECT r.session_id, s.program_name, r.status, r.command, r.wait_type, r.wait_time AS wait_time_ms, r.last_wait_type
FROM sys.dm_exec_requests AS r
JOIN sys.dm_exec_sessions AS s ON s.session_id = r.session_id
WHERE r.wait_type = 'ASYNC_NETWORK_IO';

The program_name column shows the application name reported by the connection. Use it to find the client to investigate. An empty result doesn’t rule the wait out. Repeat the check while the operation runs.

You’ll also see people check sys.dm_os_wait_stats for this. That view totals completed waits since SQL Server started, or since someone cleared the statistics. It covers the whole instance, not one session. So take one reading, wait a minute, and take another:

SELECT wait_type, waiting_tasks_count, wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type = 'ASYNC_NETWORK_IO';

In my test, the total grew by 6,824 milliseconds while the slow client ran. It grew by 379 milliseconds during the fast control. Both queries need VIEW SERVER PERFORMANCE STATE on SQL Server 2022 and later, or VIEW SERVER STATE on earlier versions.

What to Change

Stop the loop. Use one query that returns 4,000 rows, not 4,000 queries that return one row each. Many of these loops come from an ORM, a library that turns application code into database queries. The fix is to tell it to load the related rows in the same trip.

Ask for less. SELECT * sends every column, even the ones the application never shows. Ten unused columns on 200,000 rows is real extra data for the client to receive. If the client keeps the result in memory, those columns also use memory.

Move the work to the data. Say the application pulls a million rows only to add them up. Let SQL Server add them up and send back one number. In my experience, this is the biggest win in most of these cases.

Move the application closer. Sometimes the application ends up in one region and the database in another, after a migration. No query tuning will fix that delay. Every round trip pays for the distance.

Why This Keeps Happening

We reach for database tools, and database tools measure the database. They help us measure query execution, but they don’t explain every part of the application’s response time. The extra time can come from the client, connection handling or the network, and those tools don’t look there.

So the next time someone says the database is slow, don’t open a query plan first. Ask them to run the same thing on the server, and write down both numbers.

If both runs are slow, check server execution time and waits before choosing what to tune. If they don’t match, the difference tells you where to investigate next. It doesn’t prove that either the database or the network is at fault.

If your application is slow and you can’t find where the time goes, this is the kind of problem I work on with teams. You can see how a consulting engagement works on my consulting page.

A slow application is not proof of a slow database, it is proof that time is going somewhere.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.

First appeared on SQL Server Network Latency: When the Database Isn’t the Slow Part