I am working with PostgresPreparedStatements at the moment and I am running into some issues. Odd issues (and YES it is the programmer and not the framework). I do things like below
and it throws an error 22. Which is that maps back to Postgress Error Class 22, it is a data mismatch error. (there error codes is 4-5 digits in length)
Now my question has nothing to do with the bad code above. Is there a way to see what the SQL statement is in a prepared statement once all the binding have happened? tracking down what I have done wrong is a PITA. And if could just see the SQL at runtime that would be ten kinds of awesomeness.
I agree, it would make debugging so much easier. I haven’t found a way of seeing the Prepared statement with bindings (a SQL injection version), so I write a manual SQL injection binding which would show, as Norman states, the issue. That is a lot of work to find a small issue though.
I am just trying to figure out how to inject the proper date format in the SQL bindings so I an insert the data into the database. And cuz little issues like this, I am pulling out what little hair I had left.
What does “seeing the Prepared statement with bindings” mean ???
Do either / both of you mean “show me the statement with the substituted values in their respective places” ?
Unless the database API has such a facility, which most API’s dont, there’s nothing to see
The API literally sends the sql with the markers in it then transfers the data in binary form usually to the “server” (or db engine in the case of SQLite and it handles everything)
But this particular error is not an error in VALUES bound - its bind TYPES
There is no bind type for “Xojo date” for any db
FWIW most prepared statement cannot take a Xojo DATE as a parameter
Passing a string that is in the format the DB can accept as a date should work
[quote=348821:@Norman Palardy]What does “seeing the Prepared statement with bindings” mean ???
Do either / both of you mean "show me the statement with the substituted values in their respective places ?[/quote]
yes that is what I mean
[quote=348821:@Norman Palardy]Unless the database API has such a facility, which most API’s dont, there’s nothing to see
The API literally sends the sql with the markers in it then transfers the data in binary form usually to the “server” (or db engine in the case of SQLite and it handles everything)[/quote]
never said it was a Xojo issue. Just said I wished I knew how to see it.
[quote=348821:@Norman Palardy]But this particular error is not an error in VALUES bound - its bind TYPES
There is no bind type for “Xojo date” for any db
FWIW most prepared statement cannot take a Xojo DATE as a parameter
Passing a string that is in the format the DB can accept as a date should work[/quote]
very true. I didnt know if the DB driver translated the date into the proper formatting or not. Good to know that it doesnt take a date object.
Different DB engine may provide different ways to view this IF they provide them at all
Few have any way for a client program like Xojo (or the app you write) to view the SQL that the execution would be equivalent to
And this isn’t the only language where this has been asked for
Variations of this have been asked elsewhere
[quote=348846:@Norman Palardy]Different DB engine may provide different ways to view this IF they provide them at all
Few have any way for a client program like Xojo (or the app you write) to view the SQL that the execution would be equivalent to
I feel a little better that other languages dont have it either. Just a little.
per your earlier suggestion, I am playing around with the logging on the postgresql server and seeing what it says… lots of data, until it gets to that insert, then it says . with user/database is redacted.
2017-09-03 22:13:36 UTC [1781-9] ***@********** ERROR: invalid input syntax for type timestamp with time zone: "$3" at character 88
That is when I changed the schema to use timestamp with timezone.
this is previous with timestamp without timezone.
2017-09-03 20:43:01 UTC [1259-1] ***@********** ERROR: invalid input syntax for type timestamp: "$3" at character 88
that looks like the server is trying to parse a literal “$3”. Maybe you did accidentally quote the placeholder in the SQL string?
If you enable full logging with the following options, you should get the full SQL statement and the content of placeholders in the server log to explore.
db.SQLExecute("SET log_statement TO 'all';")
db.SQLExecute("SET log_min_messages To 'info';")
db.SQLExecute("SET log_min_error_statement To 'info';")
sorry I didn’t notice the SQL in question was already posted in the thread. I’m pretty sure that’s the reason for the error. Column uuid seems not to be defined with type uuid otherwise “$1” would not be accepted as input for this column as well.