Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 283
  • Last Modified:

Money column shows 0 in query, filters as blank?

Hello Experts,

I'm having a strange problem with a table.  I'm importing XML data into a loading table then inserting/updating to a final table.  There are 20k+ rows in the final table, and 499 of them contain "blank" cost fields.  Here is the query I use to determine this:

select cost from mytable where cost = ''

Open in new window


This shows data like this:

Cost
0.00
0.00
0.00
etc.

The cost field is a money datatype.  The xml source data has a 0 for this field.  During the import I use a data conversion task to convert everything from the xml file to "String [DT_STR]".  The load table has cost setup as a varchar datatype.  That's all I do as far as data conversion.  The cost column does not have a default binding set or anything like that.  However when queried it returns these 0.00 rows as blanks.  They aren't being counted as NULL, just blank.  This causes a big headache when trying to report off these rows and using functions like SUM, AVG, etc...

Any ideas why these specific rows are coming back as "blank", even though they show 0.00, and how to fix them so they return as 0?
0
jay-are
Asked:
jay-are
  • 5
  • 5
1 Solution
 
Scott PletcherSenior DBACommented:
It's not "showing" or stored as blank.  SQL is converting the empty string/"blank" to 0.00 when it converts it to the money data type.

SELECT CAST('' as money)

If they show as blank coming out of the table, it's because 0.00 is being edited to blank.

If you want 0.00 to be NULL, run an UPDATE on the table changing 0.00 to NULL.
0
 
jay-areAuthor Commented:
Since I'm querying a money data type column that contains a blank it shows 0.00 in the query results?  Should I set the default binding for the cost column to 0?  Would that avoid future confusion on my part?  :)
0
 
Scott PletcherSenior DBACommented:
The money data type does not "contain" a blank.

When you compare a blank to it, SQL converts the blank to 0.00, then does the comparison.

Again, run the statement below and you'll see that blank can't  be stored in a money data type:

SELECT CAST('' as money)
0
Visualize your virtual and backup environments

Create well-organized and polished visualizations of your virtual and backup environments when planning VMware vSphere, Microsoft Hyper-V or Veeam deployments. It helps you to gain better visibility and valuable business insights.

 
jay-areAuthor Commented:
Ok so there is actually a Null value for Cost that is being stored as 0.00 since I have the data type for that column set as money?
0
 
Scott PletcherSenior DBACommented:
Hmm, probably not NULL.  You probably loaded an empty string '', which SQL converted to 0.00.

If you need NULL instead of zero, change that in your load:

INSERT INTO ... ( ..., Cost, ...
SELECT ..., NULLIF(Cost_In, ''), ...

Or, if you want all zeros to always be NULLs, UPDATE the table accordingly:

UPDATE table_name
SET Cost = NULL
WHERE Cost = 0.00
0
 
jay-areAuthor Commented:
I'm not sure why it would convert the source data (which shows 0) to an empty string, but I do have a string conversion taking place during my initial import.  

Assuming that an empty string was loaded into this table, how do I update it so these rows aren't returned when I query where cost = ''?  I don't want that condition to exist.  I tried updating the table and setting cost = 0 where cost = ''.  It says it updated the rows, but the original query still returns the same rows.
0
 
Scott PletcherSenior DBACommented:
If the data type is money, an empty string CANNOT be loaded into that column, period.  Instead, the space is converted to 0 because of data type precedence.
0
 
jay-areAuthor Commented:
Right, it tried to insert an empty string into the money field and it was converted to a 0.  Got it.  Why does the query:
 
select cost from mytable where cost = ''

Open in new window


return data then?
0
 
Scott PletcherSenior DBACommented:
Because SQL converts the '' to a 0, then compares.

In more detail:
SQL follows rules of data type precedence.  SQL can only compare compatible data types.  If you compare two data types that are not compatible -- such as Money and string -- SQL must be able make them compatible before comparing them.  Since money has a higher precedence, SQL implicitly and automatically first converts the string to money, then does the comparison.

Character data will always be converted before being compared to numeric data.  SQL will attempt the conversion even if it fails, because SQL must make the data types compatible before it can compare them:

SELECT CASE WHEN '9' > 11 THEN 'True' ELSE 'False' END --F
SELECT CASE WHEN '9' > '11' THEN 'True' ELSE 'False' END --T
SELECT CASE WHEN '9A' > '11' THEN 'True' ELSE 'False' END --T
SELECT CASE WHEN '9A' > 11 THEN 'True' ELSE 'False' END --Conversion error!
0
 
jay-areAuthor Commented:
I appreciate you taking the time to explain this.  I realize I'm hard headed!  I guess I need to work on the import of the xml to ensure there aren't any empty strings before inserting into this table.
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 5
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now