Question

Is there a way to rewrite a Transact SQL statement that uses a CASE WHEN structure to do the same without using the CASE WHEN?

I’m using a product that has a built-in query designer and its own pseudo-SQL. It has limitations on what I can use with SQL Server and Oracle. So I have this column that, when the underlying database is Oracle, uses DECODE (which is supported). However, I need to make it work with SQL Server and CASE WHEN is not supported.

The statement I’m trying to convert is something like

Decode (StatusColumn,  'Value 1',
Decode(Sign(Now()-TargetDateColumn)),1,'Past
Due', 'Outstanding'),  'Value 2',
Decode(Sign(Now()-TargetDateColumn)),1,'Past
Due', 'Outstanding'),  'Value 3',
Decode(Sign(Now()-TargetDateColumn)),1,'Past
Due', 'Outstanding'),  'Value 4')

I have a limited set of T-SQL options to use and CASE WHEN is not an option. I do have IsNull and Coalesce, but I’m not sure if they will help me with this one.

Don’t bother with the date calculations, those are solved.

I searched the CASE WHEN questions here, to no avail.

Thanks!

Update:

I realize that I should have given more details on the reason for the limitations, as this is a developer’s resource and it would be assumed that this is a development product. It is not.

I’m using an enterprise software product that has a built-in query designer and its own pseudo-SQL. It has limitations on what I can use with SQL Server and Oracle. Basically, everything that doesn’t break the parsing of the built-in query engine is game. That means all the sanctioned functions and expressions, plus all the data abstractions (internal objects that correspond to a physical table in a database and other queries created with the product), plus everything from Oracle SQL or Transact SQL that does not explicitly break the parsing.

The reason why CASE WHEN doesn’t work for me is that it breaks the parsing of the pseudo-SQL by the query engine.

Ultimately, I would like to try to:

1. Use only the product’s query
   designer the SQL that passes the
   parsing OR
2. Use a few extra resources from
   the SQL Server database and the
   query designer to get it done.

Based on the several good answers that I got, here’s the approach that worked out for me, so far.

Jason DeFontes suggested that I could use a database view to perform the CASE WHEN rules and that falls into #2 above. It works for me because a view is dynamic enough that I don’t have to do maintenance on it (as opposed to richartallent’s truth tables approach, which I believe are close to Jason’s approach). Pascal’s suggestion of creating a function would go along the same lines, but probably break the parse.

So I created a database view that does all the transformation with CASE WHEN and I added it to my query’s SQL, joined it with the existing SQL and it worked just fine. I realize that I’m probably adding an overhead to the database engine, as it will have to retrieve the same data set twice (one for the view and one for the query), but it’s one of those cases where it’s hardly an issue.

Given that this “use a view to obfuscate it” design works for me, I wonder what would be the more efficient approach:

• Using a select with CASE WHEN;
• Using CTE (again, richardtallent);
• Using Union All (HLGEM);
• Using Subqueries (MisterZimbu);

I will still check Aramis wyler’s suggestion, as it could probably fall into #1 above.

For now, Jason’s answer was accepted. Considering that I used CASE WHEN in the view, perhaps the title for the question ended up being is ill-chosen. I upped everybody that suggested something that helped in the process. I don’t know if that makes a difference in your reputation or not, but I thought it was the nice thing to do.

Again, I want to thank you all for your help and ask you kindly to edit anything on the question that you fell is not appropriate (it’s my first question and English is my second language).

Answer 1

Can you move the CASE/WHEN logic into a view, then have the tool query the view?