So I have a requirement for a report where the user can select the exact batch number or if they are too lazy to remember the number they can pick the owner, the year, the month then the actual creation date of the batch.
If batch number is selected no need to select all the other stuff.
When the report starts up it starts in the opposite start state than expected. The query for Owner is
IF (ISNULL(#BatchNumer, '') = '')
begin
select distinct CashReceiptOwner as Label,CashReceiptOwner as Value
from CashReceiptBatchPosted
end
I was expecting the Owner box to be active, than if batch number is not empty for it to be disabled. That is not a huge issue as the combo box is blank, the bigger issue is that the report says it is required even though it is suppose to all blanks. Now I don't want to check the allow null option because all that does is create a checkbox which the user has to select.
Hopefully I made that clear enough, does anyone what I am doing incorrectly?
Related
So we have a SSRS report that displays some information about a product but we will like to update said product. The example I was given goes as follows
Name
Location
Price
Action
Orange
Earth
$100
Update
After clicking the Update word ... the price value changes.
Name
Location
Price
Action
Orange
Earth
$150
Update
Im hoping I can link the word "Update" to a stored proc that we have that will do all the magic.
Thanks
You can do this but it is not elegant.
I'm assuming you need some way of providing the new price, so that could be a parameter.
Let's take an example where you provide a price increase or decrease as a simple parameter in your report which is going to be passed to a stored proc along with the item selected in order to do the update.
First step is to create a report which looks like the example you provided. Add a parameter to this called say, pPriceAdjust. Allow blank values and set blank by default. We need to do this so the report runs initially without a parameter value being set.
Once that report looks OK, leave it to one side for now, we'll come back to that later.
Now create a new report, let's call it _sub_PriceAdjust. Add 4 parameters called pName, pLocation, pPrice, pAdjustment .
Next add a dataset query that look something like this..
UPDATE myTable SET Price = #pPrice + #pAdjustment
WHERE [Name] = #pName and [Location] = #pLocation
SELECT CONCAT(#pName, ' in location ', #pLocation, ' was updated from ', FORMAT(#pPrice, 'c2'), ' to ', FORMAT(#pPrice + #pAdjustment, 'c2')) as ReturnText
You could (and probably should) create a stored proc to do this but for the sake of simplicity it can just go directly in the dataset query.
All we have done is updated the record and then return a message as the dataset query result which can be displayed in the sub report.
Now, add a textbox to your subreport and set it to be the ReturnText field from the dataset. probably something like =FIRST(Fields!ReturnText.Value, "myDataSetName") . Make sur ethe text box is big enough to fit the whole message in.
Finally, for this subreport, add another textbox, maybe format it to look like a button, and set it action to Go To Report and choose your original report as the target, this will allow the user to click a button to get back to the original report (although the report toolbar back button might be better)
Nearly there....
Go back to the original report and in your "Update" textbox, go to properties and set the Action to Go To Report. Choose the _sub_PriceAdjust report and then add each of the 4 parameters and set their values, the first three will be the Field values from the main data set which you should be able to choose from a drop down, the final parameter (pAdjustment) will be the pPriceAdjust parameter we setup right at the start of this. There is no reason the pPriceAdjust parameter could not be called pAdjustment but I named them differently so you could see how each interacted.
Anyway, that should do it. Not pretty but it should work. There is some obvious error checking to add (is the adjustment value zero or blank for example, but I'll leave that bit to you.
To replicate your example, run the report, type 50 into the parameter and click "update" on the selected line. This should add 50 to the select price. To decrease the price back to the original amount, change the parameter to -50 and hit update.
This is completely from memory so might not be perfect but if there is something you can't figure out leave a comment and I'll refine the answer.
I've a Customer form with a tab control that holds the details for the specific items that a customer has: Ground Rent, Electricity and Garage. They may hold all 3, just Ground Rent and Electricity, or just a garage. If they don't have an item, the tab is hidden.
The issue only appears on the Garage tab: I intermittently get #ERROR in the amountdue text box. If I close down the customer and re-open them, sometimes it clears itself (with no action performed). Sometimes it doesn't. Sometimes it needs me to reopen a few times before the value shows.
The box concerned is: txtActualAmountDue and the source is the following:
=iif([tenant],[txtNet],[txtGarageCharge])
Tenant is a form data source Boolean (that indicates whether the Ground Rent/Electricity tabs should be shown).
txtNet = [txtGarageCharge]-[txtVAT]
txtVAT = [txtGarageCharge]*([txtVatPercentage]/(1+[txtVatPercentage]))
The next two are locked textboxes to make life easier
txtGarageCharge = DLookup("[GarageCharge]","Variables", criteria that returns the current row of variables for the current date)
txtVatPercentage = DLookup("[GarageVat]","Variables", criteria that returns the current row of variables for the current date)
The only thing else I can think of to mention is that if the customer is not a tenant, then txtNet and txtVAT are hidden. I sometimes get #Type! in txtNet and txtVat too - and obviously I also get the #Error - but not always: sometimes they're valued okay and I still get the #Error. I've commented out the load/current method lines that hides those textboxes to see if it's that, but it's made no difference.
Like I say - it's not like it happens every time: Just occasionally. Could it be to do with the order in which things are being valued/populated on the form? And once it's been populated once (the values will be the same for every customer) then it's okay? And if it's this, how do I force it to value the text boxes in the right order?
It is probably a timing issue, so try avoiding the mid calculations:
txtNet = DLookup("[GarageCharge]/(1+[GarageVat])","Variables", criteria)
txtVat = DLookup("[GarageCharge]/(1+[GarageVat])*[GarageVat]","Variables", criteria)
or, ultimatively:
=IIf([tenant],DLookup("[GarageCharge]/(1+[GarageVat])","Variables", criteria),DLookup("[GarageCharge]","Variables", criteria))
Using Report Builder 3.0 against cubes which are produced overnight.
The report I'm designing is used to archive or transfer (physical) files for patients. Users run the report, print it & then attach it to files that are then sent to a central area which will archive/send the files on.
The report has a number of parameters which is designed to return a single patient. This all works fine.
One of the parameters (#prmReason) is a single choice on what is to happen to the files, eg, "Transfer" (transfer files to another office), "Archive - closed", "Archive - deceased", "Archive - excess" (office space is limited, so staff archive off 'older' files).
One of the fields returned is CloseReason. This field always has a value. If the field is empty in the database (as the client hasn't closed), then it will contain the value: "Unknown".
This field (amongst others) are either displayed or hidden, depending on #prmReason. Again - all working without a problem.
Now for the tricky bit.
If the #prmReason = "Archive - closed" or "Archive - deceased" then the report will display CloseReason.
The problem is if CloseReason = "Unknown" then I need to know the why the file is closed & display it on the report.
I want users to be able to choose a value from a list of closure reasons. I then want the choice to be displayed on the report. Obviously if there is a genuine reason then display this value.
So the effect I'm after is:
User selects parameters & runs report.
Report then checks to see why report is being run (eg #prmReason).
If #prmReason =("Archive - closed" OR "Archive - deceased") AND CloseReason = "Unknown"
Then somehow produce a list of CloseReasons that the user can select. This value is then displayed on the report.
I can even cope with it being a free text field. Just something so that the central area can update the database if necessary & save a phone call/email etc.
(Yes, I realise that I can have the list as a series of tickboxes that the user ticks after the report is printed, but this would be a useful ability in other reports).
EDIT: empty value of CloseReasons conflicted with stackoverflow formatting (sorry didn't review post properly). Value is actually less then symbol then the word Unknown and then greater than symbol. It doesn't really affect the problem
You could add an additional hidden parameter.
If this parameter is not set then display an small table on your report that has a list of CloseReasons.
You then set table cell's action property to open the a report, choose your existing report as the report to open but this time you can pass a value for the final parameter, which, as well as displaying the Close reason in your report, would also hide the close reason choices table described above.
UPDATE To make clear more clear.
The following is based on the Northwind sample database. I have a shared data source pointing to this database.
Create new report.
Add a data source pointing to the shared Northwind data source
Add a new data set pointing to the data source above with the following query
SELECT
EmployeeID,
FirstName, LastName, Address, City, Country, Title, Notes
FROM Employees
WHERE EmployeeID = #EmployeeID
Add some of the fields to the report to show some basic info.
We now have a simple report with a single parameter #EmployeeID
Next we want to show some actions for each employee. For flexibility, I'm making this list dynamic based on the employee's Country. This list could be static.
Create a new dataset dsActions with the following query
DECLARE #actions TABLE(ActionID int, ActionLabel varchar(20))
-- Get employees country
DECLARE #Country varchar(20) = (SELECT Country FROM Employees WHERE EmployeeID = #EmployeeID)
IF #Country = 'UK'
BEGIN
INSERT INTO #actions VALUES
(1,'Sack them'),
(2,'Buy them a pint'),
(3,'Promote')
END
ELSE
BEGIN
INSERT INTO #actions VALUES
(1,'Fire them'),
(2,'High 5 them'),
(3,'Ask them to run for office')
END
SELECT * FROM #actions
Add a table to the report to show these values.
At the moment my design looks like this. (All the expressions are simple fields from the first dataset to show the employee details, nothing special)
And when I run it I get this.
OK, now all the basics are done, we need to be able to call this report again, but with an action already chosen. We'll make the actions table clickable and pass the action's label to the report.
It's the same report, we will only ever have a single report.
First, add a new parameter called action to the report and make it hidden. Add a default value of 'noaction'.
Next we want to only show our actions table if the action parameter is set to 'noaction'. To do this, set the Hidden property of the action table (tablix) to the following
=Parameters!action.Value <> "noaction"
Next we want to add a text box that displays the result action parameter, but only when the action parameter is not noaction.
So add a text, set it's expression to =Parameters!action.Value and the hidden property to =Parameters!action.Value = "noaction"
Finally, we need to make our actions list call our report but with a specific action. To do this we need to modify the actions table.
First save the report, whatever name you choose is the name you will select as the target report as the report will call itself.
Right-click the cell that contains the ActionLabel and go to the text box properties.
Select the Action tab and then choose "Go to report". Choose the name of the report you are currently working on (this actual report as the report will call itself).
Set EmployeeID parameter to [#EmployeeID] and the action parameter to [ActionLabel]
I've used the label for simplicity but you could pass the ActionID as long as you account for this in the text box that displays the action.
Optionally you could format the text so it looks like a link,
The final design and action/parameter setup looks like this
When I first run the report I get the following...
As soon as I click one of the actions, I then get this...
Hopefully that's clear now.
I am attempting to maintain and fix a horribly out-of-date CRM designed by an ex-employee ~4-5 years ago in Access 2007. I have brought it into Access 2013 and fixed a ton of stuff up, but I am still running into many problems.
I spent a good 4 hours today attempting to figure out why certain values didn't line up. These values were being pulled from a SELECT statement on a Combo Box over a stored Query which simply returns a table with a few extra rows. Great.
However this value (a number) doesn't appear to correlate with what we expect. I enter in one value, save the ticket, and a completely different value gets stored into the table. Opening up the ticket, I see the value that I expect. Digging deeper, I found the following difference:
Set value_1 = Me.RegistrationID // What's being stored in the table
Set value_2 = Me.RegistrationID.Column(0) // What we expect
Surprise surprise! This is a Combo Box and some value is being stored in the table. The Control Source is "RegistrationID" and the Row Source is the query in question.
However I do not know what it is! This specific value correlating to the Combo Box appears to pull the correct data when we later open the tickets. However I have a strong feeling that this could be why many tickets from before one of the rows was deleted all appear to have invalid RegistrationID's.
How badly can this break?
How easily can we correct tens of thousands of tickets?
How can I fix this to store the correct value?
This is what I expect is happening.
Your combo box row source is based on a Select query which returns and displays multiple rows. For example:
Select RegistrationID, CustomerID, CustomerName From MyTable;
The Control Source for the combo box is bound to RegistrationID which is part of the Forms Record Source.
The issue is the bound column. If we set the bound column in our example to 1, then we get the behavior your are describing with:
Set value_1 = Me.RegistrationID - Set's value to CustomerID (may appear correct)
Set value_2 = Me.RegistrationID.Column(0) - position 0 from our query (RegistrationID)
Further building on our query example, you can say:
Me.TextBox1 = Me.RegistrationID.Column(0) - RegistrationID
Me.TextBox2 = Me.RegistrationID.Column(1) - CustomerID
Me.TextBox3 = Me.RegistrationID.Column(2) - CustomerName
The RegistrationID is what normally should be stored in the table.
As long as your form shows any values that directly relate to this RegistrationID you're fine.
I would start by checking to see under the format setting to see if column widths are set properly and I would also check under the data section to see if the bound column is correct. I might also throw in an after update macro/vba sub routine that saves the record. Hope this helps.
I've got a table with 5 columns, the first 3 of which allow the user to drill down through the levels of detail. Each of these columns (Region, Country & Office) has an associated Parameter so the user can select the geographic region for their report. Each parameter allows the selection of multiple values.
If the user selects 1 Region, 1 Country and 1 Office it's not exactly ideal for them to then have to expand each selection. Is there an expression I can enter somewhere to state that if only 1 value is entered in a parameter then that data set will automatically show as expanded?
This is in SSRS 2008 R2 if that makes any difference.
In the Group Properties for the detail group you can enter an expression for the initial visibility. Right now you probably have that set to "Hide." The expression needs to return a Boolean and could be something like:
=Parameters!Country.Count <> 1
This will have SSRS hide those rows if more (or less) than one value are selected in the parameter Country
But I have seen some unexpected results with this: test thoroughly. In my experience, BIDS handles these better than SSRS itself, so just when you think you've got it all working, it fails miserably once deployed. (Reason number 14 to have a test folder on production SSRS.)