Unable to insert beyond 4000 character - sql

I am trying to insert a value(eg O20040601120101SYSONEBNPENDING20040601101010Y00405) into oracle db with the data type long, But I am getting an error saying
Error report:
SQL Error: ORA-01704: string literal too long
01704. 00000 - "string literal too long"
*Cause: The string literal is longer than 4000 characters.
*Action: Use a string literal of at most 4000 characters.
Longer values may only be entered using bind variables.
I tried using clob also but not able to solve this please help me in this.

The maximum for one time insertion is 4000 characters (the maximum string literal in Oracle). However you can use the lob function dbms_lob.append() to append chunks of (maximum)
4000 characters to the clob.
See Here
This is useful

As stated in a previous comment, you should not use the LONG datatype. It's been deprecated many years ago...
If you are using Oracle 12c, remember that you can use VARCHAR2 datatype too. It's been extended to store up to 32767 bytes!

Related

Error in source oracle connector stage which is performing just an extract

I am facing below error in a job in the source oracle connector stage which is performing just an extract.
The OCI function OCIStmtFetch2 returned status -1.
Error code: 1455, Error message: ORA-01455: converting column
overflows integer datatype. (CC_OraStatement::fetch, file
CC_OraStatement.cpp, line 1,820)
What is the data type in Oracle? Typically Oracle specifies NUMBER, which can have as many as 38 digits. An Integer can have at most 10 digits.
If you import the table definition from Oracle, it will give you a data type for that column with which you can work. Or - if you must use integer - you can use user-defined SQL to CAST that column AS INTEGER, but you may still hit "too large" problems in this case.

How to store emoji characters in DB2 database?

I have an application that it's storing tweets in a DB2 database, and need to retrieve them in some moments. I'm having troubles showing text string with emojis inside (some emojis loose the format).
I've been reading different answers in internet, but most are for MySQL (switch from utf8 to utf8mb4), but nothing for DB2...
Is there any way to do something like the following in DB2 databases?
https://mathiasbynens.be/notes/mysql-utf8mb4
Thanks too much
You can use Unicode constants like this in a Db2 Unicode database
$ db2 "values U&'\+01F600'"
1
----
😀
1 record(s) selected.
https://www.ibm.com/support/knowledgecenter/SSEPGG_11.5.0/com.ibm.db2.luw.sql.ref.doc/doc/r0000731.html
U& followed by a sequence of characters that starts and ends with a string delimiter and that is optionally followed by the UESCAPE clause. This form of a character string constant is also called a Unicode string constant.
A character can be expressed by either its typographical character (glyph) or its Unicode code point. The code point of a Unicode character ranges from X'000000' to X'10FFFF'.
To express a Unicode character through its code point, use the Unicode escape character followed by 4 hexadecimal digits, or the Unicode escape character followed by a plus sign (+) and 6 hexadecimal digits. The default Unicode escape character is the reverse solidus ()
or you can use UTF-8 HEX values if you prefer
db2 "values x'F09F9880'"
1
----
😀
1 record(s) selected.
Could you clarify what is the issue? With UTF-8 database there is no issues with the linked example
$ db2 "create table emoji(string_with_emjoi varchar(32))"
DB20000I The SQL command completed successfully.
$ db2 "insert into emoji values 'foo𝌆bar'"
DB20000I The SQL command completed successfully.
$ db2 "select string_with_emjoi, hex(string_with_emjoi) string_with_emjoi_hex from emoji"
STRING_WITH_EMJOI STRING_WITH_EMJOI_HEX
-------------------------------- ----------------------------------------------------------------
foo𝌆bar 666F6FF09D8C86626172
Code point for emjoi is stored with 4 bytes (0xF09D8C86). If you have an issue displaying the emoji after retrieval you need to dig a bit deeper and see what is the actual value returned by the database - problem very well might be in the application itself.

ORA-01704: string literal too long when migrating database

I migrate some data from a database and get it in a data.xml file
Example:
<insert tableName="ORG_CUSTOMER">
<column name="My-Column" value="a very long string.."/>
</insert>
I then execute it with a cmd command
call ..\liquibase\liquibase-bin\liquibase.bat --changeLogFile=%DATA% --defaultSchemaName=NAME_DBA --defaultsFile=liquibase-local.properties update
And because the value sometimes is longer than 4000 characters i get the error:
Unexpected error running Liquibase: ORA-01704: string literal too long
The column is of value clob. The autogenerated xml file contains a lot of inserts I would prefer to not edit it manually. I read something that making it a prepared statement or using pl/sql will work but I don't now how to do that?
Oracle - by default - has a limit of 4000 byte for string literals.
If you are on 12.1 or newer you could raise that limit to 32k.
If you are using an old version or can't change the parameter, you can't use Liquibase's <insert> change.
You could try the <loadData> change and hope it uses a PreparedStatement, in that case the limit doesn't apply:
http://www.liquibase.org/documentation/changes/load_data.html
Without the code of liquibase.bat it is difficult to say but.
From the documentation on literals:
Text literals have properties of both the CHAR and VARCHAR2 datatypes:
Within expressions and conditions, Oracle treats text literals as though they have the datatype CHAR by comparing them using blank-padded comparison semantics.
A text literal can have a maximum length of 4000 bytes.
I would guess that the script is naively converting the XML from:
<insert tableName="ORG_CUSTOMER">
<column name="My-Column" value="a very long string.."/>
</insert>
To
INSERT INTO {tablename} ( "{column.name}" ) VALUES ( '{column.value}' );
and this will fail when the text literal has more than 4000 bytes.
To fix this you will need to edit the script to handle CLOB values with more than 4000 bytes (where you cannot use a text literal).

SQL Server : truncation error with plenty of room in char destination data type

I am attempting to do an insert from a select statement in SQL Server 2008 R2. The destination column's data type is char(7) and I have verified the len() and datalength() of the source column to be no longer than 6.
I am getting truncation error:
Msg 8152, Level 16, State 14, Line 219
String or binary data would be truncated.
I have verified using temp tables that an insert into a char(9) column works, but unfortunately the destination database will not support the data type change.
UPDATE: I was able to do the insert as required by adding a DISTINCT clause to the select statement in question, however the number of rows remains the same. So, I guess the reformatted question is why does adding the distinct clause return no error message even if the data is the same? Thanks!
What character set are you using? Some character sets have characters that take up two bytes. However the length function will still count them as 1.
I agree with Bill and David. But if most of the characters from your source are multi-byte then (some characters even take up 3 bytes) then you may need to use something like varchar(50) just to make sure your field is big enough to avoid truncation errors.

Trapping Exception using TSQLQuery & params

I am getting a "SQL Server Error: arithmetic exception, numeric overflow, or string truncation" error
here is the code below
AQuery:= TSQLQuery.Create(nil);
with AQuery do
begin
SQLConnection:- AConnection;
SQL.Text:= 'Insert into.....';
ParamByName('...').asString:= 'PCT';
.
.
.
try
ExecSQL;
finally
AQuery.Free;
end;
end;
I have alot of ParamByName lines, and I can't figure out which one is throwing the exception. I just know its thrown on the ExecSQL line. How can i tell which paramByName is causing the error?
When you have the metadata of the table, check the maximum length of string fields. When debugging, check the length of the strings you feed the parambynames. Also check the type of numeric fields, and make sure you don't exceed a maximum value. (I had this problem once with a string which length exceeded the varchars length in the table, and had this problem with a smallint databasefield that I tried to set to a too high value)
Get the SQL text after param substitution and run it as a query in SQL Server management studio.
You'll be able to debug it from there.
You are trying to insert a string value into a field that is not big enough to hold the value. Check the length of the values you are inserting against the length of the field in the table.
As others have said, it's almost certainly that you are pushing too-large a string into one of your fields. It could also happen with numeric values but it's most likely to be a string.
I'd suggest you temporarily alter each of your ParamByName('').AsString:=blah lines with a text constant, eg;
ParamByName('surname').AsString:='Smith';
ParamByName('firstname').AsString:='John';
etc, and see if you get an error. If it goes through without an error, then your problem is most likely to be that one of your string parameters is too long. Check your table schema and debug the actual strings you are putting into the parameters.
Depending on how much access (and experience) you have with this, you might find it more helpful to turn on the SQL Server logging such that you can see your queries (and the contents of those parameters) when the get processed by the SQL server. This will show you exactly what string and numeric values are actually being given to the server.
Which version/edition of SQL Server are you using?