I have the following setup.
'Apps/Reports' <---------> 'DB2 Connect' <------------> 'Legacy DB2 on AS400'
`Hibernate` `native calls`
When data is retrieved from by the application, it will be padded with extra spaces if the length is less that the column length. Of note when running a query, if the WHERE cause parameter is not padded, its automatically padded with extra spaces such that the query will retrieve the same records for a padded and non-padded parameter.
Is there a way (preferably on IBM DB2 Connect or connection string parameter) to remove extra whitespaces from a resultset?
You could implement an hibernate UserType that automatically trim the strings. There are good exmaples on
https://forum.hibernate.org/viewtopic.php?t=928294
http://java.dzone.com/articles/annotating-custom-types
http://santescas.blogspot.de/2014/02/creando-un-usertype-de-hibernate-que-se.html
Are the columns in the iSeries defined as CHAR()? I'm assuming so, because this is how CHAR() works -- it's a fixed field length, not a variable field length (that's what VARCHAR is for).
Related
I'd like to add a large string (above 76k characters) to CLOB column in Oracle database.
I need to run a script from liquibase framework.
How can achive this?
Simple insert
INSERT INTO table_clob (clob_column) VALUES (to_Clob('string above 72000 chars...'));
with and without to_clob() method is returning exception like:
ORA-01704: string literal too long
Cannot load data from file as described here with procedure: https://oracle-base.com/articles/8i/import-clob
as I don't have priviliges to any directory
Searched google but didn't enounter any solution for my requirement.
Any advice?
UPDATE:
After hours of searching finally found a workaround here: https://stackoverflow.com/a/49817056/1622703
It is not sufficient as I need to cut the text for 3 chunks manually (with around 30k chars), but it works.
Now just need to figure our how to do it dynamically in case that the string will have vary lenghts of chars (above 10k chars for example).
A hard-coded string enclosed in single quotes is known as a string literal. An example is 'Hello world'. Another example is the very long string you are trying to insert in the table. By contrast, 'abc' || 'def' is a string expression but it is not a string literal. Similarly, to_char(sysdate, 'yyyy-mm-dd') is a string expression, but not a literal. "Literal" means constant, hard-coded text.
The issue you are facing has nothing to do with insert, or to_clob(), or the data type of columns in your table, etc. It only has to do with the string literal itself.
In Oracle, a string literal can be at most 4000 bytes long (or 32767 bytes if the database is set up with extended MAX_STRING_SIZE). PERIOD! There is no way around it.
So, the question is, how can you ever get a string as long as the one you have into a table with a CLOB column. The answer depends on how you are receiving the string in the first place. The best option would be if it came in chunked already - as a collection of strings, with a tag (an id) to keep track of which fragment belongs to which CLOB and an ordinal number (to show if it's the first chunk, the second, etc.) Then you could re-assemble them using TO_CLOB() on the first chunk, plus the concatenation operator.
If your process is to type 72000 characters at the keyboard, you will have to type 4000 of them at a time, enclose in single quotes, and use the concatenation operator (essentially doing by hand what I described above). You would also have to use TO_CLOB() on the first fragment (otherwise the concatenation will fail).
Another option is for the string to come as a value, from some application that supports long strings (something compatible with Oracle's CLOB) and that can hand over such values to the Oracle database without the need to write out the hard-coded string in full.
So, the ball is in your court. The first question is, Where is the long string coming from in the first place?
using CGI escape i able to save some special character in DB. But I faced a critical issue related to column size.
In one case data size in one column is 12 character. when user inserted 11 spacial character in a view form. then if I escape those spacial character and try to save those whole string in DB, then it is giving a error and that is because of the length if character after escaping 11 spacial character is more than table'c column size(i.e 12 char).
How to solve this type of error ?
Here is the documentation for storing in Database with RhoMobile.
Using the Local Database with Rhom
I'm using integration services (SSIS), at the moment I'm getting the data from an excel source, the string Description comes with a length greater than 15 chars: the problem is that I can't find a way to truncate this data in order to save it in the database (the column database is varchar(15) and I can't change it).
I was trying to use a derived column in order to truncate the data with no success.
Add a derived column transformation and use the SUBSTRING function to get only the first 15 characters of the string. Read about the Substring function in SSIS here SUBSTRING SSIS Expression
Your expression in the derived column would look something like SUBSTRING(Description, 0, 15)
How can I automatically .Trim() whitespace from the results of my Linq2SQL query?
It seems that if SQL has a varchar width of 255 my returned result for "abc" will have 252 chars of whitespace.
Are using char(255) rather than varchar(255)?
If not, check the data in your database - you must be storing all those spaces in the column. Linq-to-sql will only return the column as a string. It does not pad it with spaces, and will only return the 252 spaces if they exist in your database. Are you storing all those spaces in the database? e.g. "abc______________"
I'd firstly suggest you fix your database, but if you can't do that then you can edit the generated code as Exoas suggests.
Try casting as a string:
(string)abc.Trim()
A Quick and Dirty way to make sure the fields are trimmed from your query's automatically, is to modify the designer generated getters for the fields you want trimmed to call the trim method.
get
{
return this._sometext.Trim();
}
Downside is that if you change the mappings it will be generated.
How do you guys treat empty strings with Oracle?
Statement #1: Oracle treats empty string (e.g. '') as NULL in "varchar2" fields.
Statement #2: We have a model that defines abstract 'table structure', where for we have fields, that can't be NULL, but can be "empty". This model works with various DBMS; almost everywhere, all is just fine, but not with Oracle. You just can't insert empty string into a "not null" field.
Statement #3: non-empty default value is not allowed in our case.
So, would someone be so kind to tell me - how can we resolve it?
This is why I've never understood why Oracle is so popular. They don't actually follow the SQL standard, based on a silly decision they made many years ago.
The Oracle 9i SQL Reference states (this has been there for at least three major versions):
Oracle currently treats a character value with a length of zero as null. However, this may not continue to be true in future releases, and Oracle recommends that you do not treat empty strings the same as nulls.
But they don't say what you should do. The only ways I've ever found to get around this problem are either:
have a sentinel value that cannot occur in your real data to represent NULL (e.g, "deoxyribonucleic" for a surname field and hope that the movie stars don't start giving their kids weird surnames as well as weird first names :-).
have a separate field to indicate whether the first field is valid or not, basically what a real database does with NULLs.
Are we allowed to say "Don't support Oracle until it supports the standard SQL behaviour"? It seems the least pain-laden way in many respects.
If you can't force (use) a single blank, or maybe a Unicode Zero Width Non-Break Space (U+FEFF), then you probably have to go the whole hog and use something implausible such as 32 Z's to indicate that the data should be blank but isn't because the DBMS in use is Orrible.
Empty string and NULL in Oracle are the same thing. You want to allow empty strings but disallow NULLs.
You have put a NOT NULL constraint on your table, which is the same as a not-an-empty-string constraint. If you remove that constraint, what are you losing?