MySQL has a EXPLAIN command that might be helpful.
I wonder what's your motivation for checking the syntax, what's wrong with just running the query and handle errors, if any?
--
No matter how great and destructive your problems may seem now, remember, you've probably only seen the tip of them. [1]
| [reply] |
Different databases or DBDs divide up the work between prepare and execute differently.
Why do you want to do the precheck, anyway? Why not just execute?
You could do (untested:)
my $ok = $dbh->do("explain $sql");
| [reply] [d/l] |
If SQL doesn't parse, there are no adverse effects in any way, at least on Oracle, MySQL, Sybase, SQL*Server, or PostgreSQL. I've never used other RDBMSes, so I can't say for sure, but I'd be shocked if there were.
If you're worried about reporting the issue up the chain, the consumer of your DBI wrapper generally doesn't care why something failed, just that it failed at all. I've found it best to just do the whole thing as one big prepare-execute(-fetch) black box and roll errors up from any of the parts.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
I think I saw once a module to do this on CPAN. Did you search there? Maybe e.g. SQL::Statement can help you? | [reply] |
DBD::sqlite is the engine through libsqlite, whereas DBD::mysql is a mere network client. So, until prepare actually prepares the statement on the server, you can't (unless you find some checking module/library that speaks MySQL, not just SQL).
| [reply] [d/l] [select] |
If you use the optional server-side statement handles feature in MySQL, it will give errors for bad SQL when you prepare. | [reply] |