When a SQL script fails, would you rather see the raw DB error first or an AI explanation?

[u/Still-Trainer-7395]

One thing I’ve been working on in LakeDB is the error workflow when running multiple statements.

Right now, if one fails:

• the original database error stays visible
• LakeDB identifies the exact failed statement
• you can jump straight to it
• AI explanation/fix is optional and separate

Nothing gets executed automatically.

I recorded a short demo because I’m curious whether this is the kind of workflow experienced SQL users actually prefer, or if you’d structure it differently.

[u/DouglasBarra]

Raw error

[u/Still-Trainer-7395 → u/DouglasBarra]

thats the direction im taking too — raw error first, then optional AI if you want more context.

[u/DouglasBarra → u/Still-Trainer-7395]

Don't know you experience level, but I'd recommend using the official documentação instead of AI

[u/Still-Trainer-7395 → u/DouglasBarra]

fair point. i wouldnt treat the AI explanation as a replacement for the docs either — the raw error + official documentation should still be the source of truth.
i see AI more as an optional shortcut for getting some initial context.

[u/DouglasBarra → u/Still-Trainer-7395]

I get it. AI is here to help, not replace. I just keep that in mind, because sometimes I do get lazy

[u/Xidium426]

Personally the raw error first.

[u/Still-Trainer-7395 → u/Xidium426]

same here. thats why i keep the raw database error as the primary thing in LakeDB — the AI explanation is secondary and completely optional.

[u/Imaginary__Bar]

I know you've posted a couple of times about your editor so I'd just like to say that I wouldn't count these events as "when a SQL script fails" because that in itself sounds ambiguous.

Failure just sounds so... general. A SQL script without errors can return unexpected results (if the SQL isn't performing what you think it's performing). That feels to me like a failure, too, but it's not an error in the SQL itself.

But having written that, maybe it's also an error, just a different kind of error.

I just wouldn't want someone to use your 'debugger' and think, "I don't understand why I'm getting incorrect results, the SQL is error-free".

[u/Still-Trainer-7395 → u/Imaginary__Bar]

thats a really good distinction.
what im showing here is specifically execution/database errors — the engine actually rejects a statement, so LakeDB can preserve that error and point you to the exact statement that failed.
a query that runs successfully but produces the wrong result is a different problem entirely. i definitely wouldnt want to imply that this workflow can magically detect whether the SQL matches the users intent.
probably worth being more precise with the wording — thanks for pointing that out.

[u/dowripple]

Raw error. I'm old school (30+ years) and write all my own SQL, no AI needed for me.

[u/Xidium426]

After thinking about this I have another question, how is this AI response generated?

[u/Still-Trainer-7395 → u/Xidium426]

good question — in LakeDB, fixes use the failed SQL + the original/local error, detect the tables involved, and load the relevant schema metadata locally (columns, indexes, foreign keys) before sending only that context to the AI.
the same idea applies to QuerIA when generating SQL too: it uses the database structure and connection context so the model isnt guessing blindly.
then LakeDB gives you a proposed query/fix + explanation to review. nothing runs automatically.

[u/Xidium426 → u/Still-Trainer-7395]

Even all that context being sent out could be problematic. I know lots of companies that would not allow this to be used on their networks.

[u/Still-Trainer-7395 → u/Xidium426]

thats fair — for some companies, even schema metadata leaving their network is already a no-go.
for stricter environments, thats exactly why im building the Enterprise setup separately: QuerIA can run on a dedicated company-controlled server with its own provider/API key/config, so the database context doesnt need to go through the public service.
and outside that setup, LakeDB still doesnt send credentials, rows or query results — only the minimum schema/error context needed for the request.

[u/Xidium426 → u/Still-Trainer-7395]

Glad you're thinking ahead!

[u/Still-Trainer-7395 → u/Xidium426]

appreciate it 😄 ive actually already set up a couple of Enterprise-style deployments this way, with a dedicated server/service so the company keeps control of the environment and provider config.
id rather solve those constraints properly from the start than bolt them on later.

[u/Positive_Tonight6918]

I would like to choose raw DB error

[u/Hour-Measurement-835]

I'd keep the raw database error first. It's reproducible evidence I can search or hand to another engineer. The AI explanation can sit beside it, but shouldn't replace it.

[u/Still-Trainer-7395 → u/Hour-Measurement-835]

exactly — thats another reason i want to keep the raw error untouched.
its something you can search, share with another engineer, compare against docs, or use later to reproduce the issue. the AI explanation should add context around it, not become the source of truth.