I have an application that I am building (Spring Boot, PostgreSQL); I am executing sql statements from a file sqlStatements.sql against the database. In some instances, it appears that the driver is appending a white-space character to the front of insert statements and when trying to create a function, it does not occur when defining tables though. I used the trim() method on the sql string to no avail. When logging the sql statements, there is no white-space character, but when looking at the PostgreSQL logs, sure enough, it's there. Is this a known issue with the driver? Is there a setting on the database side I need to change? Or do I need to do extract work in Java to avoid this error?
The space disappeared when pasting it here, so I added it; the sql files are all UTF-8.
Application log:
org.postgresql.util.PSQLException: ERROR: syntax error at or near
"insert" Position: 1
PostgreSQL log:
2017-03-04 10:29:26 EST ERROR: syntax error at or near " insert" at
character 1
Any feedback would be appreciated.
the file encoding was different between the various sql files. I had to set the encoding to "UTF-8" instead of "UTF-8 with BOM".
https://apple.stackexchange.com/questions/46586/textedit-removes-byte-order-mark-bom-from-unicode-utf-files-how-to-fix
Related
I am running a jdbc query and using the result set to retrieve column values.
My output goal is a csv.
I am using Jython scripting in Maximo via the automation scripts.
I notice that I frequently get errors writing lines out and in the middle of output I get missing or truncated values from the point of error.
The errors read basically:
BMXAA7837E - An error occured that prevented the BIALOCHIERREP script for the BIALOCHIERREP launch point from running.
UnicodeEncodeError: 'ascii' codec can't encode character u'\xa0' in position 16: ordinal not in range(128) in at line number 224
psdi.util.MXApplicationException: BMXAA7837E - An error occured that prevented the BIALOCHIERREP script for the BIALOCHIERREP launch point from running.
It seems logical that some data coming in from the database is not UTF-8 if I am seeing this error
I know that other processes such as BIRT are able to read this very same data and get by the 'errors'
So is there a recommended way of getting by this or determining for sure whether the data is good or bad in the source database? I am currently somewhat immersed in trying to find the bad data using debug statements.
Since you are running SQL directly against the database, I would check whether your database has cast() or convert() functions you can call to do that conversion to ascii for you.
I have been trying to execute a really long SQL query and get the result into a data frame in R. But the following line throws an error and displays partial query in the console (truncates it)
my_dataframe <- dbGetQuery(conn, my_large_query)
The length of the query is 10564 characters where I use a lot of CTEs.
I have removed the string truncation via options menu in R studio but I wonder if there a character limitation in the dbGetQuery function in R?
Any suggestions?
RDMBS: DB2 (on IBM AS400),
R Package: DBI (library - RJDBC)
You mentioned changing the 'string truncation', but how about warning.length?
options("warning.length"={integer})
I'd also suggest that you test the query out first in whatever GUI is available for your database. When you verify there's no problem with the query, then run it in R.
When dbGetQuery (assuming the DBI package) throws an sql/database error, the actual content of the error won't be shown until after the full text of the query. In other words, if the query text is being truncated in the R error output, the database error code/text coming will not be visible at all. The issue may be something extremely simple like an unmatched bracket or a missing comma.
Please note whether the error message starts with Error in dbGetQuery (R issue) or Error in .verify.JDBC.result (database issue).
I try to run several SQL-Statements in an SQL Script action for an Oracle dbms inside an installer and as part of a JDBC container action.
The script is encoded as UTF-8, and contains several statements, delimited by ";" and a new line between each statement, like this
statement 1;
statement 2;
...
The statements contain installer variables that are replaced before execution. I used the semicolon as a statement separator in the SQL script action.
The first statement throws an error
Error executing script line "CREATE user testconuser identified by xxx TEMPORARY TABLESPACE temp;",
error message: "ORA-00911: invalid character"
The statement itselfs works fine within SQLPLUS, but the problems seems to be the semicolon, that is still part of the statement executed by install4j.
In a JDBC sql statement, semicolons are not valid.
I also tried to remove the semicolons from the statements and used "\n" as statement delimiter, but then the sql script actions fires all sql statements within the script at once, so it looks like the "\n" is not recognized.
I am using install4j 6.1.5 build 6349. The platform is windows and the sql script is build on windows.
Any idea what I should change?
Any help would be highly appreciated, thanks a lot in advance,
Alex
I used the semicolon as a statement separator in the SQL script action. The first statement throws an error Error executing script line
and
I also tried to remove the semicolons from the statements and used "\n" as statement delimiter
Both are bugs in 6.1.5 and will be fixed in 6.1.6. Please contact support#ej-technologies.com to get a build where you can verify that this will work for you.
SQL ERROR
Class
com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException
Message
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'precision=3, scale=0.0, units='°C' where channel_specification_id=1196' at line 1
Context
So this error is entirely related to Unicode as the query works for other units that do not include Unicode characters. The °C is actually a Unicode ° and a char C.
It should be noted at one point it was accepting the Unicode ℃ \u2103. Additionally the db is storing these Unicode characters already, and returning the characters to grails upon query but it fails when grails attempts to update the db with any of these characters.
I have tried setting useUnicode=true, characterSet=UTF-8, adding custtumm dialects etc, and the db is set to use UTF-8 general ci as per similar questions and answers on stackoverflow, none work.
Any thoughts?
So the issue, which should have been glaringly obvious was precision! Its a key word, so we escaped the field (precision) in the domain class under mapping.
Context
We're changing our install scripts to use ant's "sql" task and jdbc rather than proprietary sql clients sqlplus (oracle) and osql (msft).
Updated: added more context. Our "base data" (seed data) consists of a collection of .sql files containing "vendor-neutral"(i.e. works both in oracle and mssql) sql statements.
The Problem
The scripts run fine, with one exception:
This sql fails in Oracle. Specifically, something (ant or jdbc driver) treats the dashes/hyphens as "beginning of a comment"--even though they are embedded in a string. Note that the same sql works fine with ant/sql and microsoft's jdbc driver.
INSERT INTO email_client (email_client_id,generated_reply_text) VALUES(100002,'----- Original Message -----');
Related Bug
This ant bug appears to identify the problem. As it's still open (after 8 years), I'm not hoping for a fix soon. However, because the problem appears only in oracle, it may lie with the driver.
The oracle driver: jdbc thin driver, version 10.2.0.1.0
The Question
Does anyone have a workaround which works in both mssql and oracle? (e.g. changing the offending lines to define an escape character? I don't see an 'escape' on the 'insert' sql92 syntax)
thanks
After viewing the 'SQLExec' source and turning on verbose logging, I found a workaround:
Workaround
if the sql statement includes a string containing '--', place the delimiter (semi-colon) on the next line.
This Fails
INSERT INTO email_client (email_client_id,generated_reply_text) VALUES(100002,'----- Original Message -----');
This Succeeds
Note that semi-colon is on a separate line
INSERT INTO email_client (email_client_id,generated_reply_text) VALUES(100002,'----- Original Message -----')
;
Details
Turning on verbose logging, I saw that when Ant came across the offending sql statement, it actually passed three sql statements in at once to the jdbc driver. The offending statement, the next statement (which also included an embedded '--'), and the subsequent statement (which did not include an embedded '--').
I gave the Ant code a quick glance and didn't see any obvious errors. Since I wasn't planning to patch Ant, I looked for a workaround.
Tweaking with it I found that if I simply moved the delimiter (semicolon) to the next line for the statements with embedded '--', the scripts executed successfully.
thanks everyone for weighing in
You could try this:
INSERT INTO email_client (email_client_id,generated_reply_text)
VALUES(100002,LPAD('-',5,'-') || ' Original Message ' || LPAD('-',5,'-'));