HELP!! parse error: Invalid numeric literal at line x, column x?! It’s not your Oracle REST API!!

A few days ago, I penned a blog post highlighting the ORDS REST-Enabled SQL Service. And in that blog, I displayed the output of a cURL command. A cURL command I issued to an ORDS REST-Enabled SQL Service endpoint. Unfortunately, it was very messy and very unreadable. I mentioned that I would fix it later. Well…it’s now…later (temporal paradox, anybody 🤨?).

Recap

If you recall, the output of my POST request looked like this:

Yikes, you kiss your mother with that mouth?!

JSON is not displaying correctly

Well, the reason why I didn’t originally pipe in the json_pp command is because this is what happened when I attempted it:

Jefe to the rescue

After reading my newly published article, Jefe suggested I try the jq command.

The Yoda to my Padawan

Which, of course, I did. Still no luck:

Different issue though

Andiamo a googliare!

Online search to the rescue

Search online using the keywords “parse error: Invalid numeric literal at,” and you’ll quickly discover that you’re not the only one with this problem.

Five minutes of research revealed a potential culprit. What I was experiencing seemed to be a known issue. For example, a long-standing jq bug on GitHub details this exact scenario. This doesn't seem to be a jqor json_pp issue. Instead, the problem is somehow related to the -i cURLcommand option and JSON parsing.

After another few minutes, as luck would have it, I found a Stack Overflow thread discussing the same issue I encountered! After scrolling to the bottom of the thread, I found this golden nugget:

Thank you Mattias and nhs503 🥰

Testing without -i

So, I did just what Mattias and nhs503 suggested. I removed the -i option (-i, or — include) from my cURL command, and wouldn't you know? The damn thing works as expected! I tested while piping jq and json_pp. I also concede that jq is the prettier of the two; I appreciate the colors (although, admittedly, this would NOT pass any accessibility testing).

The modified commands used:

curl -X POST --user ORDSTEST:password1234 --data-binary "@sportCountryMatrix.sql" -H "Content-Type: application/sql" -k http://localhost:8080/ords/ordstest/_/sql | jq

curl -X POST --user ORDSTEST:password1234 --data-binary "@sportCountryMatrix.sql" -H "Content-Type: application/sql" -k http://localhost:8080/ords/ordstest/_/sql | json_pp

And the results:

jq part one of the response

jq part two of the response

json_pp part one of the response

json_pp part two of the response

Final thoughts

And for some final thoughts…

1. It turns out it’s NOT ORDS — it’s something to do with an underlying JSON parser not liking the header info that is coming through
2. json_pp and jq work; they output the information in different order
3. The ORDS REST-Enabled SQL Service returns to you not only your results, but the SQL statement initially used (that is cool and I didn’t originally realize or mention this)

And that’s it for this one! I really hope you find this useful. I hope this saves you some time from having to troubleshoot and/or hunt for a fix for this tricky problem. That’s all for now!

Follow

And don’t forget to follow, like, subscribe, share, taunt, troll, or stalk me!

• Twitter
• YouTube
• LinkedIn
• Instagram
• TikTok
• GitHub
• Facebook
• My blog