You're missing the point of my comment. He's trying to match a potentially NULL value to another value. You can't do that with a function that is designed to return NULL. NULL doesn't match anything. It simply isn't mathematically possible to match an unknown value against a known value and get an answer of any worth. Hence COALESCE() will not work and his use of ISNULL() is entirely appropriate because he's substituting a blank string for any possible NULL response.

-------Back to the beginning--------------

RE: The money. I did research after I asked that question because it really concerned me. After looking at it, and looking at other people's responses, I disagree that there's really a math problem with this data type. It's how the data type is used (usually in equations its not meant to be used in) that would cause a problem. Having worked in Accounts Payable / Receivable for most of my life before I became a DBA, I know how to use it. One doesn't go around dividing it down until it gets past the digits it needs to be unless one is prepared to lose change.

There are certainly situations where it's inadvisable to use it, such as when you need more decimal places that money allows for, but to be fair, it's a perfectly solid data type that does exactly what it should do. No more, no less. Exactly like a lot of things in SQL Server.

So you're telling people they can't use the tools that are provided to them in the software that they use? That's just silly. Especially as most companies are so loath to change expensive software programs for another that it makes portability almost a non-issue.

I have to disagree with this one. Standards aren't standards unless everyone adopts them. You can call Blue Ray a standard if you want, it won't prevent people from buying DVD. Companies don't provide ISO rules to their programmers. Programmers aren't going to go out and buy standards books on their own. And where are the training classes? I used to work at a university that certified people in ISO standards via Conferences and other CTE classes. I can promise you that this standard was not one of them.

Not sure what rule you're talking about. A lot of the books I've read specifically instruct people to name tables, views, procs and functions using an enterprise-wide standard that tells everyone what they're dealing with when they're coding. In fact, I think I remember reading a Kimball paper that said the same thing.

What's your definition of "data dictionary"? Mine is a report I wrote up that specifically lists tables, views, procs and functions in different areas of the report and then lists dependencies on each. I don't see how my data dictionary would be screwed up by something as simple as a name.

Again, this is your personal preference, a statement of opinion, like the statement right before it. Nothing in this statement is scientific or logical. Reason 1 is the closest thing you have to an actual fact in your response. Reason 2 is skirting the line because it again depends on what books someone's been reading about data modeling.

I can see both sides of the naming argument, but nothing about either side has any "proof" that the data (or reports) will get hosed if you go one way or another on the issue. That being the case, I stand by my opinion that naming conventions are a matter of choice and the only thing that can be wrong about them is if they aren't consistently implemented across the enterprise.