wendy elizabeth (11/1/2013)
In an SSRS 2008 existing report, I have one column that I need to separate the values. I am not allowed to change the database. I am told that I need to work with the data as it is.
I don't know the syntax of SSRS but here's what works in T-SQL. You would need to replace SUBSTRING with MID and CHARINDEX with the equivalent (INSTR?) SSRS function. CHARINDEX finds the position of the first expression in the second expression starting at the optional third express)
Here's a working example. Of course, you could change @SomeString to the column name you want to parse and add a FROM clause for the table that column exists in but I wanted to keep this simple. They COULD add persisted computed columns to the table to permanently split the data without any changes to a well written front-end.
In the following, the only assumption that I made about the data is that the CustomerNumber column will ALWAYS be 3 characters as indicated by the leading zero's. Heh... having such formatted customer numbers is yet another mistake the people that designed this made. This is a really strange requirement because they want normalized data to appear in the report but refuse to normalize the data in the database where it should be.
DECLARE @SomeString VARCHAR(100);
SELECT @SomeString = '099 11-12 Midwest Plumbers';
SELECT CompanyNumber = SUBSTRING(@SomeString,1,3)
,ValidYear = SUBSTRING(@SomeString,5,CHARINDEX(' ',@Somestring,CHARINDEX(' ',@SomeString,5))-5)
,CompanyName = SUBSTRING(@SomeString,CHARINDEX(' ',@SomeString,5)+1,8000)
Here are the results...
CompanyNumber ValidYear CompanyName
------------- --------- ----------------
099 11-12 Midwest Plumbers
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs