I have read the posts about divide by zero, and using functions to overcome it, which I usually do with normal reports.
What I can't find is how to handle the divide by zero issue on calculated fields. You can't use a function because of aggregation (which calculated fields does not allow), so I do not know how to get round it.
I could write some more SQL just for this pie chart I am doing, but it is part of an existing report and ideally I want to use what is already there.
Does anybody know how to handle divide by zero issues for calculated fields?
Example: =Fields!Other.Value/Fields!Total.Value*100
Thanks,
Kevin.
It's been a while since I used reporting services, but can't you validate the Total value before doing the division? Something like this:
=iif(Fields!Total.Value>0,Fields!Other.Value/Fields!Total.Value*100,0)
Related
I have a 100% stacked bar graph in SSRS. Due to the rounding some of the categories does not add up to 100. In some instances the total would be 99 or 101.
I want to achieve the following:
1. Calculate the total of the stack
2. If the total is greater than 100 then the difference should be deducted from the smallest value in the stack
3. If the total is smaller than 100 then the difference should be added to the largest value in the stack
Is this possible?
Or what other solution is there to resolve this issue?
Thanks
Achieving this functionality dynamically within the report itself would be very difficult and likely inefficient. I would suggest doing this calculation in the database instead. For example, have your SQL query populate a temporary table, run the logic to update the table, and then return the results to the report dataset.
This depends on the type of database you're using and the permissions you have. But in general, this would be a better approach.
Try increasing the precision of the results in your data. If your percentages are at 1 or 2 decimals (100.00%), you are highly unlikely to have enough remainders to run up or down a full integer. 100.02% should still show as 100% when formatted without decimals.
I am using the following expression to tier the sales figures.
=sum(iif(Fields!InitialValue.Value>=500000 and Fields!InitialValue.Value<1000000,Fields!InitialValue.Value,nothing))
Basically, I just change the greater than and less than values for each cell. We have 4 tiers.
From what I understand, the IIF statement will go through each line and evaluate it before returning anything.
I am also averaging the size of each new account, so I have 8 cells that evaluate the data each time. I will also need to add how many accounts are in each tier, which means 12 passes at the same data. It takes some time to generate this report.
Is this the most efficient method?
Thanks in advance for all your help!
One way you could increase the efficiency at this, from what I can tell is one of two way, the way I would do it is add a column to your query that labels each row by Tier, this would mean when the data gets to SSRS it is already set and never needs to be evaluated. My theory is SSRS is not as smart as a query optimizer. Another way to do it, that may or may not speed it up, is add a calculated field to your data set that especially does the same thing. I believe this would have SSRS calculate it once and that is is.
Each returned transaction I am to report on is stored with a return reason code and a description of the return reason code. I built a tablix with two columns - one for return codes and another for descriptions. This works just peachy. The report owner is upset that a long list of codes will split pages - sigh. I was told to display them side-by-side.
I am new to t-sql and SSRS and its idiosyncrasies. I have minimal support from our DBAs. Two tables, filtered to display codes that meet a criteria sound simple enough.
My research:
MSDN's support network, Operators in Expressions page, and various help topics. I also found SO posts regarding split functions in t-sql and similar as well as one specifically asking about comparison and varchar. I found sites with helpful information like ResultData and Network Steve. I haven't found what I think I'm looking for.
My problem:
The return reason code is a varchar that always consists of the letter 'r' and two numeric digits (R00 to R99). It appears I can't run a comparison operator on an entire varchar that is alphanumeric; it doesn't recognize IIF((Fields!... <= R17),True,False). Additionally, the company will not allow the warehouse or its functions to be edited so I cannot create my own.
My solution ideas:
Add each Rnn code to the tablix filter, individually. This means ~50 filters per tablix and seems a sloppy or inefficient way of handling this
Separate the varchar string in to its alpha and numeric components and compare the latter using standard operators. This sounds the cleanest method but I'm unsure how to accomplish this in an expression or within SSRS
Forgo the two-table idea and create one table with four columns (code, description, code, description). This still leaves me with how to set a limit on the number of rows that can be created before 'spilling over' to the other side
I appreciate being pointed to any resources or any offered input to the issue and my (not so?)logical approach to it.
You can achieve your second option as follows:
CInt(Fields!ReturnCode.Value.Substring(1,2))
I'm creating a report that has an unusual BoxPlot chart. I need to calculate the values for "Low Box" and "High Box" using all of the data for the certain column. The methodology for calculating these values is not that complicated, but I can not disclose it.
Basically I want to create a custom aggregate function. I understand how to create a VB function, but how do I make it take in a series of data instead of a single value. I know there is a Max function already, but for the sake of example how would one implement a Max function?
Thanks for your help.
"can not disclose it." implies high value, which implies that you are using a recent version of SSRS, so this link should be of value for you. (The blog article also includes how you might implement this in 2005, but doesn't focus on it.)
Essentially create a custom function that gets called for every row of the data, taking in values from that row. That method or another related method can return your aggregate. 2008 includes Group Variables should help with a convenient place to store that.
Another approach, but much harder I think, would be to implement a custom data provider wrapping your query.
I need to use a percentage in my Rails app. In any view, including when it is entered by the user, the format will need to be the hundreds format, 100.000. When it's used in calculations, it needs to be represented in the hundredths format, 1.00000.
My migration (I'm adding the column to an existing table) has the following line:
add_column :worker, :cash_split, :decimal, :precision => 6, :scale => 5
So, as of right now, I'm storing it in the hundredths (1.00000) format. My basis for choosing to store it in this format is that i figure it will mean cleaner business logic (i.e. no worker.cash_split / 100.0.to_d code hanging around) when i need to do multiplication.
My only other thought was maybe abusing the composed_of method. I could store the data in the hundreds (100.000) format as cash_split and then make an attribute accessor cash_split_percentage that returns cash_split in its 1.0000 format counterpart.
Your first thought is the right one...don't overthink it.
You should definitely store percentage numbers in the database in hundredths format. And use that format in all of your Ruby calculations.
Percentage figures are a display convention. Eg the number 0.45 is displayed as 45%. As such, use a View helper to convert your percentage figures from their internal format (decimal numbers) to your chosen display format--a string which includes the % sign.
It depends.
First off, I don't think there is a right way or a wrong way. It's your app and your code, so you can do what you want, but you should do what makes the most sense for your circumstances.
As #BishmaStornelli commented in #LarryK's answer,
How would you handle percentages in forms? Users will want to enter it like 45% but it should be stored as 0.45. Nevertheless, if the user inputs another field wrong and the form is re-rendered, the percentage field sould have 45 and not 0.45. With this I want to say that a callback may not be the final solution.
You're damned if you do and you're damned if you don't. You either clutter up your calculation code with divisions by 100, or you clutter up your Model and Views with converting from a decimal to a percentage and back again.
I suppose the answer depends on which is more heavy in your application.
If you are conducting lots of calculations based on this percentage then storing it as a decimal would seem like the best approach that will provide the least amount of code and the clearest, cleanest code to view and maintain.
However, if you are not conducting lots of calculations based on this percentage (maybe only a couple) then it may make more sense to not have to write a bunch of code in the Model and Views to display the decimal as a nice percentage, and just divide by 100 when you need to perform a calculation.
In our particularly case, and the reason I ended up here, we want the User to enter the value as a nice percentage, like 75%, in the form. And we always want to display this value in Views, Reports, etc. as a nice clean percentage, like 75%. And we only need to perform a calculation with this value a couple of times.
So, it makes sense in our case to store the value as a percentage in the database. It makes saving and viewing much easier, and only incurs a "divide by 100" penalty in the couple of spots we perform a calculation on it.
Hopefully, that helps others and provides a different viewpoint to the already well-written and accepted answer.
Thanks #BishmaStornelli for the alternative perspective!