AI Experiments: Claude Solved a DAB Issue

I’m sure many of you are using AI regularly, perhaps chatting, perhaps using some sort of agent. I’m doing the same, but in this case, I had it tackle an issue that’s been inconsistent for me with the Data API Builder and it solved it. Something I’ve struggled to do with docs and Google.

This is part of a series of experiments with AI systems.

The Scenario

I’ve been doing some work with the Data API Builder, letting it provide me access to data through REST and GraphQL. Lately, it added MCP as well, and I’ve been updating a talk as well as experimenting with this.

However, I’ve struggled to get Stored Procedures to work. They have sometimes worked, sometimes not, and I’ve not quite figured out why. Now that I know, I feel a bit silly, but recently I decided to let Claude help me solve this.

I typically use Northwind, and the DAB docs have been a little light. They have exmaples, and I’ve gotten these to work, but when I’ve moved to more standard Northwind things, this hasn’t always worked.

I should have seen a pattern, but it’s a lot of data, docs, and different places I’ve seen searches. This felt like a place an LLM might see something I didn’t see. It’s also a way to speed up work when I’m busy and not focused on this problem for hours at a time.

Using Claude for Help

This felt like a “chat” thing, so I picked the chat item in Claude desktop and gave it context: my dab call the error, the fact the proc executes in the correct security context. I got this back. Claude response in Italics.

Ugh. Me see problem. Flag wrong. No shaman flag call “–parameters.name” exist. Fake flag. DAB no understand.

Real flag call –source.params. Fix like this:

Note: I’ve set Claude to talk like a caveman for now, which reduces output.

I pasted in the doc page, and then got this:

2026-07_0275

The more interesting part of the response was Claude noting that sp_describe_first_result_set is called and needs a good response. I hadn’t thought about this, so I decided to run it. I have the response to claude and it evaluated this as correct.

It next suggested adding dev mode (already on, it didn’t have my whole config) and turning the log level up. That’s a good idea. It also asked me for the section of the config file to be sure the proc was in there correctly.

I did all those things. It verified my config blocked was correct.

2026-07_0277

Claude then asked me to try both the REST and GRAPHQL APIs and gave me the code for those. I pasted the error in and it suggested that I might have an issue with the URL code I used in Bruno. Maybe, but worth a try. It gave me the CURL command.

2026-07_0278

The Solution

It was at this point that I started to realize the issue. The proc that wasn’t working used an NCHAR() as a parameter. The DAB call expects string. It gave me this response and an example of the code for my config file.

CustOrderHist proc expect nchar(5) param, but DAB parameter type system only know few kind: string, number, boolean, etc — no raw “char” concept. Missing "type" field make DAB fall back some default guess (maybe try char/byte path), boom, exception.

Add "type": "string", restart engine (dab start again — config file, not hot reload), fire query/POST again. String type push CustomerID as varchar/nvarchar-like, proc side (nchar) accept fine via implicit convert.

I changed things and tried it, but it wasn’t working. We upped the debug level and I pasted in results, which are annoying to go through. DAB doesn’t include a timestamp (I opened an issue) so I had to sort through the output to find the log items.

I pasted in the logs and then Claude found the issue. It explained things, which I don’t care about since this is an API thing. However, it gave me a couple of choices for fixes. I changed the parameter in the proc, which isn’t a tiny change, but it’s also not a big change.

2026-07_0279

It didn’t work at first, but when I pasted in my query, it recognized that BRUNO might be an issue.  The response explains this and says to try CURL. I did, but I also realized that my GraphQL command was a GET, not a POST.

2026-07_0280

This worked, and I tried a few more stored procedures to verify I had an idea of what to do.

Summary

There wasn’t anything amazing that Claude did here, but I approached this as if I were struggling with a problem and asked a colleague. I was a little shorter than I might be in Slack messaging or email, but I was really dumping some results on a co-worker and letting them sift through things.

What was most amazing was that I had a few other things happening at this moment and I’d focus on this for an experiment and then let Claude examine logs while I went to try something else, edited my GraphQL queries or even answered an email. I solved the problem with help, but wasn’t spending a lot of focused time because I had an assistant.

This is something I do more and more. Let me assistant do something and come back. I’ve struggled with this problem for months since I didn’t have a lot of continuous hours to spend digging through logs and docs. Not sure I’ve even seen this particular solution come up in my Google searches, but certainly Claude made it easier than it has been previously.

Unknown's avatar

About way0utwest

Editor, SQLServerCentral
This entry was posted in Blog and tagged , , , . Bookmark the permalink.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.