I have a situation in BIRT reporting. A report I created is insisting on displaying some fields as blank rather than zero. The situation arises when the field is actually a sub-select that returns no rows.
So for example, if the select includes:
0 as p3,
then the 0 is displayed okay. If however, the select has:
(select sum(other_field) from other_table where ...) as p3,
the field is displaying blank.
Modifying the data so that rows exist for the sub-select results in a value being displayed, even if their resultant value is zero.
So I'm thinking that somehow BIRT is treating a sub-select returning zero rows as a NULL (which it also displays as an empty cell) rather than a zero. Does anyone have any idea how to coerce BIRT into displaying an actual 0 rather than an empty cell?
I'm using DB2/z v8 if anyone needs to post a DBMS-specific answer, although even suggestions based on other vendors would be appreciated.
Try using the COALESCE function to force a value when a column or expression might return NULL.
COALESCE((select sum(other_field) from other_table where ...), 0) as p3,
Another way, although not as elegant but sometimes necessary (e.g. if your are executing a stored procedue that you cannot change), would be to use JavaScript to force the display of "0" at run time.
Use the following expression for your data binding:
if (dataSetRow["your_data_set"] == null)
{
0
}
else
{
dataSetRow["your_data_set"]
}
Depending on the data type you might need to add quotes to the zero
"0"
to represent Strings, without quotes it is treated as an Integer.
While using decimal data I was able to do a quick +0 to the field as a shortened version.
dataSetRow["your_data_set"]+0
Related
I have a table that holds drafted data. Most of the values on the table are nullable. I want to return an empty string in the case the value is null and I'm grabbing and copying the draft data onto the frontend. What would be the best way to handle this? I understand I can use ISNULL(variable, '') but don't want it to do that for every single value. Or a ternary on the front end to return a empty string if null. Would there be a better way to handle this?
You can have a trigger on your table before insert or update and populate the fields you want with an empty value for all values that match your "treat null as empty" rule.
In my opinion changing data model to satisfy UI requirements is not a great idea. I would rather have a transformer in the middle (or a custom RowMappeer) that will do the transformation on the data already pulled from the database.
Also note that for some databases (such as Oracle) an empty string and a null are interchangeable in which case my suggestion to use a trigger won't work.
I know you said you did not want to use ISNULL but this is the main reason this function exists so I would rather start using it. If you have lots of such fields you can always use a clever editor to help you build your query using ISNULL rather than typing.
You can use the nvl sql function, which allows you to change null value for any value you want.
I have a RDBMS table in DB2 where a column is defined as "ARMTST" VARCHAR(10) NOT NULL DEFAULT
I was checking data on table and see rows with no value in this column ( Via Toad Viewer) but when I run this query , SELECT COUNT ( * ) FROM ACTIVITY WHERE ARMTST IS NULL; I get result as zero rows.
Attached is screen shot for SELECT ARMTST FROM ACTIVITY ; which shows empty column values for certain rows.
Are these columns not empty even though shown so in UI? Default value is not specified in CREATE TABLE script.
I don't think that code will be able to insert empty values.
An empty string is not null (well, except for on Oracle, but people hate them for that). Often in databases, null is used to represent "we don't know (yet)", while empty is "not present".
Consider middle names. Many people in America (and other countries) have middle names (not your given name, not your family name).
If you (casually) ask me for my name and I respond with only a first and last name (likely, in my case, or you might only get my first name!), what do you know about my middle name? Nothing. You don't know if I have one. This is null - you don't know if I have one, and if so, what it is.
But if you ask me "officially" (like for legal reasons), I'm obligated to use my full name - if I have one (or more), I have to include my middle name. So there's two outcomes here:
I have no middle name. That result is blank - we know the answer, and it was nothing.
I have a middle name. The result is whatever my name is.
Or consider signing up for a website. Before signing up, you are not in their system. Your entire record is null - it doesn't exist. After signing up, though, you get a 0 post count.
So now you should have enough information for your question.
Obviously, because the column was defined as NOT NULL, you can't put a null there. So the system has to default to something else. Since including any data (including a space character - yes, there is one) would make a poor default, the system chooses an empty string. And since the empty string makes an acceptable default, it will also be an acceptable data value to insert.
Which approach is better to use:
BoundField.NullDisplayText isn't set. NULL-case is foreseen in SQL query, i.e. SELECT ISNULL(amount, 0) FROM table
or
BoundField.NullDisplayText is set, e.g. "0.00 %". NULL-case isn't foreseen in SQL query, i.e. SELECT amount FROM table
What do you think?
Clearly the first one, because you filter with ISNULL.
I would argue that the second choice is better. It is generally better to format output in the middle-tier or presentation tier rather than the database. Thus, I would want to return nulls to the tier above the data tier code and have it decide what to do about display rather than make the choice at the database.
By converting nulls to zeros, you are stating for all systems that use the query that a null equates to a user intentionally entering a zero. If that is actually the case, then fine, use Coalesce instead of IsNull and convert nulls to zeroes. However, if there is even the remotest possibility that the query will be reused and that the absence of a value might be treated differently than the entry of a zero, I would return nulls to the middle tier and let it decide what to do about it.
Can you do best of both?
ISNULL only serves this single case
Formatting/logic should be in the UI
Other clients using "amount" may expect NULL so you now have an inconsistent "contract"
0 means zero, NULL means unknown/nothing: 2 different states
The difference is that 0.00 implies that the field has a value, whereas NULL implies that the opposite. From a data sanity perspective, therefore, the former is correct.
In MS-Access database, table called NewTable3
colname is a text column containing lot of empty cells or blanks.
i want to put ? character in empty cells . when i run the query
UPDATE NewTable3 SET colname = '?' WHERE ISNULL(colname) ;
This query updates 0 records why . what is wrong with this query
Two quick things:
1) Try putting the colname in square brackets.
2) Remember that empty cells (Nulls) and empty strings ("") are different.
Together:
UPDATE NewTable3 SET [colname] = "?" WHERE ISNULL([colname]) OR [colname] = "";
Also, are you running the query in Access itself, or just using the Access engine and using the data in another program/via a VBA script? It can make a difference.
EDIT:
Based on #onedaywhen's prodding, I now see that I never fully absorbed the original question, which was asking about replacing Nulls with the literal ? character. This is insane and not helpful or useful. If you don't have a meaningful default value for the field, then LEAVE IT NULL. If you want to distinguish between Null (unknown) and Blank (i.e., known to be blank), you can allow zero-length strings and change the Nulls to ZLS.
My original post follows, since I think it is useful for people who might get to this crazy question needing to do things properly:
In total, all the answers in this thread end up solving all the problems with the original SQL statement, but they do so incompletely, so I'll compile them all together in an attempt to create a comprehensive correct answer.
#Wim Hollebrandse wisely points out that a parameter needs brackets, but posts the SQL as:
UPDATE NewTable3 SET colname = '[?]' WHERE ISNULL(colname);
This is incorrect, in that the quotes will cause what's inside them to be treated literally, instead of evaluated as a paramter, so you'll end up with all your fields updated to the literal value "[?]". The correct syntax would be:
UPDATE NewTable3 SET colname = [?] WHERE ISNULL(colname);
#GuinnessFan points out a problem in the WHERE clause, suggesting out that the result of IsNull() needs to be compared to True in order for the WHERE clause to work. In other words, this:
WHERE IsNull(NewTable3.colname)
...should be this:
WHERE IsNull(NewTable3.colname)=True
But given that both statements evaluate the same, they are entirely equivalent. But #GuinnessFan is correct that this is the best syntax:
WHERE NewTable3.colname Is Null
#mavnn points out that the fields may be "empty" while not being Null, which is a very common problem. I believe on principle (and consistent with my understanding of the official SQL standards) that fields should be initialized as Null and should not allow zero-length strings. It is certainly possible in some applications that one might want to distinguish Null, i.e., value not yet supplied, from blank (zero-length string), i.e., value known to be blank. But if that's part of the application design, then the user should know that criteria on such fields need to consider whether one or both should be included (i.e., both Null and <>"" or one or the other).
From my point of view, it was unfortunate that the the old default for text fields (where AllowZLS defaulted to FALSE) was changed in Access 2003 to allow ZLS's by default. This means that many people who don't notice that AllowZLS is set to TRUE when they create their tables end up with ZLS's stored in their text fields without intending to do so (and importing a table from a previous version also defaults to TRUE).
While testing for Null and ="" will make the WHERE clause that is seeking all "empty" fields work as expected, the permanent fix is to change the field definition to disallow ZLS's. But do note that changing AllowZLS to FALSE does not clear the existing ZLS's -- you have to run a SQL UPDATE to remove them.
Last of all, in using parameters, it is better to declare them such that the values that the user can input are restricted to appropriate values. If the field is numeric, you to limit it to numeric values, if a date, date values, if text or memo, to text:
PARAMETERS [User Prompt] Long;
UPDATE MyTable SET LongIntegerColumn = [User Prompt]
PARAMETERS [User Prompt] DateTime;
UPDATE MyTable SET DateColumn = [User Prompt]
PARAMETERS [User Prompt] Text ( 255 );
UPDATE MyTable SET TextColumn = [User Prompt]
Note that with Text(255) as your parameter type, anything supplied by the user is truncated to 255 characters, even if it's longer than that (it would be a pretty unusual situation where'd you'd need that). For values longer than that (such as memo fields), you omit the text length declaration:
PARAMETERS [User Prompt] Text;
UPDATE MyTable SET TextColumn = [User Prompt]
In any event, I think so-called anonymous parameters are not too helpful, as you aren't leveraging the power of parameters to restrict data type of input criteria.
Try:
UPDATE NewTable3 SET colname = '[?]' WHERE ISNULL(colname);
The questionmark is used for anonymous parameters, so you need to escape it as above. Note that I have not tried this.
UPDATE NewTable3 SET NewTable3.colname = "?"
WHERE (((NewTable3.colname) Is Null));
To keep your function: WHERE (((IsNull([NewTable3.colname]))=True));
I don't believe that replacing the NULL value with your own 'magic' value ? will cause you anything but further pain.
Here's hoping you may draw inspiration from this article:
How To Handle Missing Information Without Using (some magic value)
Due to a weird request, I can't put null in a database if there is no value. I'm wondering what can I put in the store procedure for nothing instead of null.
For example:
insert into blah (blah1) values (null)
Is there something like nothing or empty for "blah1" instead using null?
I would push back on this bizarre request. That's exactly what NULL is for in SQL, to denote a missing or inapplicable value in a column.
Is the requester experiencing grief over SQL logic with NULL?
edit: Okay, I've read your reply with the extra detail about this job assignment (btw, generally you should edit your original question instead of posting more information in an answer).
You'll have to declare all columns as NOT NULL and designate a special value in the domain of that column's data type to signify "no value." The appropriate value to choose might be different on a case by case basis, i.e. zero may signify nothing in a person_age column, but it might have significance in an items_in_stock column.
You should document the no-value value for each column. But I suppose they don't believe in documentation either. :-(
Depends on the data type of the column. For numbers (integers, etc) it could be zero (0) but if varchar then it can be an empty string ("").
I agree with other responses that NULL is best suited for this because it transcends all data types denoting the absence of a value. Therefore, zero and empty string might serve as a workaround/hack but they are fundamentally still actual values themselves that might have business domain meaning other than "not a value".
(If only the SQL language supported a "Not Applicable" (N/A) value type that would serve as an alternative to NULL...)
Is null is a valid value for whatever you're storing?
Use a sentry value like INT32.MaxValue, empty string, or "XXXXXXXXXX" and assume it will never be a legitimate value
Add a bit column 'Exists' that you populate with true at the same time you insert.
Edit: But yeah, I'll agree with the other answers that trying to change the requirements might be better than trying to solve the problem.
If you're using a varchar or equivalent field, then use the empty string.
If you're using a numeric field such as int then you'll have to force the user to enter data, else come up with a value that means NULL.
I don't envy you your situation.
There's a difference between NULLs as assigned values (e.g. inserted into a column), and NULLs as a SQL artifact (as for a field in a missing record for an OUTER JOIN. Which might be a foreign concept to these users. Lots of people use Access, or any database, just to maintain single-table lists.) I wouldn't be surprised if naive users would prefer to use an alternative for assignments; and though repugnant, it should work ok. Just let them use whatever they want.
There is some validity to the requirement to not use NULL values. NULL values can cause a lot of headache when they are in a field that will be included in a JOIN or a WHERE clause or in a field that will be aggregated.
Some SQL implementations (such as MSSQL) disallow NULLable fields to be included in indexes.
MSSQL especially behaves in unexpected ways when NULL is evaluated for equality. Does a NULL value in a PaymentDue field mean the same as zero when we search for records that are up to date? What if we have names in a table and somebody has no middle name. It is conceivable that either an empty string or a NULL could be stored, but how do we then get a comprehensive list of people that have no middle name?
In general I prefer to avoid NULL values. If you cannot represent what you want to store using either a number (including zero) or a string (including the empty string as mentioned before) then you should probably look closer into what you are trying to store. Perhaps you are trying to communicate more than one piece of data in a single field.