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.
Related
I am using Oracle's SQL*Loader to import flat files into the database. Is there an explicit NULL string in SQL*Loader, like \N in PostgreSQL, that can be used instead of an empty string? Or is there an option in the control file that can be used to set a NULL string, e.g. NULL AS ''?
Like Alex said, empty fields are treated as NULL in Oracle. You may need to set default values or conditions on your table itself if you want to differentiate somehow. You might be able to find a solution to your issue from here using the WHEN, NULLIF, and DEFAULTIF Clauses.
Ex from the docs:
fixed_field CHAR(2) NULLIF fixed_field=BLANKS
But ultimately, I don't know how you differentiate between empty fields and null fields in a flat fixed-width file. Either the data is present or its position filled with white space. Unless you have specific rules that you're going to apply to make that determination, I don't see a difference between the two.
I need an urgent help from you guys, the thing i have a column which represent the full name of a user , now i want to split it into first and last name.
The format of the Full name is "World, hello", now the first name here is hello and last name is world.
I am using Derived Column(SSIS) and using Right Function for First Name and substring function for last name, but the result of these seems to be blank, this where even i am blank. :)
It's working for me. In general, you should provide more detail in your questions on places such as this to help others recreate and troubleshoot your issue. You did not specify whether we needed to address NULLs in this field nor do I know how you'd want to interpret it so there is room for improvement on this answer.
I started with a simple OLE DB Source and hard coded a query of "SELECT 'World, Hello' AS Name".
I created 2 Derived Column Tasks. The first one adds a column to Data Flow called FirstCommaPosition. The formula I used is FINDSTRING(Name,",", 1) If NAME is NULLable, then we will need to test for nullability prior to calling the FINDSTRING function. You'll then need to determine how you will want to store the split data in the case of NULLs. I would assume both first and last are should be NULLed but I don't know that.
There are two reasons for doing this in separate steps. The first is performance. As counter-intuitive as it sounds, doing less in a derived column results in better performance because the SSIS engine can better parallelize the operations. The other is more simple - I will need to use this value to make the first and last name split so it will be easier and less maintenance to reference a column than to copy paste a formula.
The second Derived Column is going to actually perform the split.
My FirstNameUnicode column uses this formula (FirstCommaPosition > 0) ? RTRIM(LTRIM(RIGHT(Name,FirstCommaPosition))) : "" That says "If we found a comma in the preceding step, then slice out everything from the comma's position to the end of the string and apply trim operations. If we didn't find a comma, then just return a blank string. The default string type for expressions will be the Unicode (DT_WSTR) so if that is not your need, you will need to cast the resultant into the correct string codepage (DT_STR)
My LastNameUnicode column uses this formula (FirstCommaPosition > 0) ? SUBSTRING(Name,1,FirstCommaPosition -1) : "" Similar logic as above except now I use the SUBSTRING operation instead of RIGHT. Users of the 2012 release of SSIS and beyond, rejoice fo you can use the LEFT function instead of SUBSTRING. Also note that you will need to back off 1 position to remove the comma.
In Oracle I try to find all the rows that contains some diacritics in one column. I used something like:
where regexp_like(name,'(Ă|Î|Ș|Ț|Â)','i');
The problem is that it also returns rows that contain the letters without diacritics (A,I,S,T). For example the clause above will return a row that contains "Adrian" as name.
How can I search only for diacritics?
Thank you
The way diacritics is handled in comparisons and when sorting is a property of the session that depends on the value of NLS_SORT. See Linguistic Sorting and String Searching
I think it may be caused by character conversion.
What do you get when you run the query?:
select 'ĂÎȘȚÂ' from dual
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).
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?