odbx_query(3)

👑 odbx_query(3) — the OpenDBX girlie's guide to yeeting a statement at your DB 💅

okay so bestie, this is odbx_query(3) from the OpenDBX manual, and it's literally the main character of the whole "talk to your database" arc. buckle up 🎀

---

✨ NAME ✨

odbx_query — send a statement to the database server. that's it. that's the vibe. 🦋

---

🌸 SYNOPSIS 🌸

#include <opendbx/api.h>

int odbx_query (odbx_t* handle, const char* stmt, unsigned long length);

---

💖 DESCRIPTION 💖

okay so what this does: it sends the statement you give it (stmt, we'll get there) over to the database server that's already attached to handle — and that attachment happened back when you called odbx_init(). it's just "here, database, go execute this bestie" 🔥

about non-displayable characters in your statement — you can have them as arguments in conditions, no cap, but they gotta be escaped via odbx_escape() before you add them. and honestly? more than that — every single argument whose source isn't controlled by the programmer must be escaped first. why? to avoid SQL injection attacks, which, um, avoid serious harm?! 😭 this is the part where you don't skip steps. please. for me. 🙈

about what comes back — once you invoke odbx_query(), the server sends back one or more result sets, and you get at them via odbx_result(). but here's the thing the way that this is important: before those sets are processed by calling odbx_row_fetch(), you literally cannot send any other queries to the database server. none. zero. if you try anyway, odbx_query() will hand you back a backend error straight from the native database library 💀 respect the queue.

about handle — this is the connection object that was created and returned by odbx_init(). and heads up, it becomes invalid the moment you supply it to odbx_finish(). so like, don't do that and then keep using it. 🫶

about stmt — the statement you store here must be a valid statement that the receiving database server actually understands (each server has opinions, iykyk), and it should be terminated by a \0 character. also some backends support multiple statements per query — you can test whether yours does by calling odbx_get_option(). slay for the multi-statement backends ⭐

about length — this must contain the length of the statement in bytes, without the terminating \0 character. and if variable sized character sets like UTF-8 are in play? same rule applies, no exceptions. this function does not support the wide character type (wchar_t), which uses two or four bytes per character — so don't even try it 💅 but here's the cute part: if you feed 0 (zero) as the length parameter, it will calculate the size of the statement on its own. self-sufficient icon behaviour 👑

---

🌈 RETURN VALUE 🌈

odbx_query() returns ODBX_ERR_SUCCESS, or an error code whose value is less than zero if one of the operations couldn't be completed successfully 😔 the possible error codes are listed down in the errors section, and you can feed them to odbx_error() and odbx_error_type() to get further details — like a little error explainer, we love her 🧚

---

💜 ERRORS 💜

• -ODBX_ERR_BACKEND — the native database library returned an error because it wasn't able to handle the statement correctly. not her fault, not your fault, but also definitely somebody's fault 😭
• -ODBX_ERR_PARAM — either handle or stmt are NULL, or handle is invalid. check your params bestie 🍓
• -ODBX_ERR_NOMEM — allocating the required memory for the statement failed. out of memory, out of luck 💀

---

⭐ SEE ALSO ⭐

• odbx_error()
• odbx_error_type()
• odbx_escape()
• odbx_result()

---

real talk: escape your arguments. every argument whose source isn't controlled by the programmer. odbx_escape() exists for a reason and it is not decorative 💅

---

and that's the whole page, bestie 🫶 this was OpenDBX, dated 6 February 2026 — go forth, query responsibly, and remember: no unprocessed result sets before you send the next one. periodt ✨🎀🦋