I've inherited an SSRS report that doesn't work correctly. The report is a meta report of a document management system. FWIW, this is a monthly destruction report -- certain documents to be destroyed per retention policy. The kicker in this application is that there are special "stack_location" values that represent certain content status, e.g. 86/86/86 meaning document checked out but not returned. Any given document can have only one stack location, or one special stack location value.
The basic query returned all the appropriate documents. The original designer, then created a filter list that excluded all the special values. This is as intended. However, the designer apparently assumed these special value exclusions could be toggled by clicking on a radio button in an options section. This, of course, does not work. Indeed, the whole approach seems off.
I think I need a default query that includes an AND NOT IN ('86/86/86', '96/96/86'...), then somehow optional unions with the special values. I am completely at sea, however, on how to accomplish this.
It seems it would be relatively straight forward if I were just using VB, or C#, to write different dynamic queries based on the value of a radio button. I am required, however, to use SSRS, technology I'm only vaguely familiar with.
If anybody can point me in the right direction, I would be most appreciative.
Thanks.
You can pass the radio button's value to the query, then as you suggested, include in your where clause something like
AND (StackLocation NOT IN ('86/86/86', '96/96/86'...) OR #MyRadioButton = 'SomeValue').
Related
I developed a dynamic Access report using "On Format" and "On Print" Event coding, and now I want to move over to SQL and SSRS, and I was wondering if there is ANY WAY at all, to capture the functionality offered in Access + VBA in SSRS. Frankly, I think it's absurd that this level of functionality is missing.
Reason being, previously I allowed users to merge text boxes in data entry by putting a "======" next to the column they want merged across, and the code would just extend the width across the "======" fields during printing.
Specifically, I have a Report with close to 20 text-boxes in each row, and any of them could be merged any which way in any random row, depending on where the users put the "======".
Meaning, if I would go the standard road of having many rows and just setting the visibility conditionally, I would need an enormous permutation of rows to capture all the possible merged cell layouts.
Currently, I am considering using RDCE, but I am not totally sure it will do what I need since the documentation is so scarce. Frankly, I am more wondering if there isn't some way to replicate the "on format" event coding in SSRS?
EDIT:Note, ultimately the goal would be to automatically generate their reports online, so is there some way of coding for events on the online rendering?
Situation
I have a report which is to be export by customers to excel format when they please that must meet certain formatting criteria.
Problem
This report is a statutory return that must be returned in a specific format. I have decided this can be achieved with the use of pivots. Instead of a list view they require a grid of totals, like this
o...
This can be done manually by writing out lots and lots of pivots in a big complex statement, but would need to be updated as soon as the column I am pivoting on has a new entry, which will be frequent.
Perfect Solution
The perfect solution for this would be for somebody to find something magical that automatically pivots on all data in one column and does so programmatically, so if entry's are added to that column, they will also be pivoted on.
I am not looking for exact code here because that's lazy and I won't learn anything. A shove in the right direction would be nice though, if this is at all possible.
You can do this with dynamic SQL (Example in this answer). Although this is frequently best achieved through an application/reporting layer rather than directly in SQL.
In your case you can embed reports in Windows Forms Applications, which gives the option of just viewing the report, or exporting in a number of formats. If the pivot needs to be done in SQL then dynamic sql is the only way to do it.
I have a table consisting of three columns; the first is an ID, the second describes the activity assigned to that ID and the third defines the category that the activity falls into. I have a combo box, which contains a list of all of the categories lifted from another table. I would like to have a second combo box, which, on selection of a specific category, allows the user to pick an activity from that category.
My knowledge of access and databases is quite limited, so any help would be appreciated.
This is a fairly complex thing to actually do, but it is doable. If you're dead set on it, it will require learning a bit of both VBA and SQL. You essentially need to write VBA code that will first define SQL queries as a string based on your choice in the comboboxes and then passes that string as the source of each following combobox.
If your experience with access and databases is limited as you say it is, you may want to opt for a simpler solution for the time being. If you want to see more in detail how something like this would work check out http://www.fontstuff.com/access/acctut15.htm
There is a walkthrough here at MSDN on synchronizing two comboboxes. It is a common feature so internet searching will locate other similar examples.
In a typical business application it is quite common to have forms that are used for searching.
Some basic features are:
A pane that contains the search criteria
A grid to display the results
Sorting on the grid
A detail page that opens when an item is selected in the results grid
What other features would you expect in a business application's search functionality?
Maybe it's a bit trite but there is some sense in this picture:
removed dead ImageShack link
Do it as it shown at the second example, not as at the 3rd one.
There is a well known extreme programming principle - YAGNI. I think it's absolutely appliabe to almost any problem. You always can add something new if it's necessary, but it's much more difficult to remove something what is already exist because someone already uses it even if it's wrong.
How about the ability to save search criteria, in order to easily re-run a search later. Or, the ability to easily, cleanly, print the list of results.
If search refining is allowed (given a search result, limited future searches to the current results), you may also want to add a breadcrumb system, so that the user can see the sequence of refinements that lead you to the current result-set -- and by clicking on a breadcrumb, return to a previous refinement stage.
Faceted search:
(source: msdn.com)
This is displayed in the area in the right ellipse. There are filters and the engine shows the number of results that will remain after aplying the filter. This is very useful and can be done without pain in some search engines, such as Apache Solr. Of course, implement this only if filters make sense in your task.
Aggregate summary info, like total(s), count(s) or percentages.
One or more menus, like right click context for the grid, a ribbon or menu on top.
Your list for the UI elements is kinda good. Export, print (asking them whether it is really necessary to print this?), category/tag and language selection is worth to consider. Smart and working pagination (don't forget ordering).
Please do not force a search to open in a new (or even worse, always in the same window). Links of search results should be copy-pastable (always use GET),
But it really matters to have a functional (i.e. a really good) algorithm. Mostly I google company websites, because their search engine is, cough, awwwwkward. Looking for a feature chart, technical spec, pricing etc. one is not interested in press releases and vica-versa.
Search engine providers offer integration into company websites.
Use Auto-complete wherever possible on your text input fields.
If using selects or combo boxes with related information try and use chain selects to organise the information.
Where results depend on location try and serve relevant results.
Also remember to keep the search form as simple as possible even down to one text field. To refine the search you can have an alternate form as an "Advanced Search interface".
Printing, export.
A grid to display the results
Watch out not to display results a user is not authorized to see (roles / permissions / access rights).
A detail page that opens when an item is selected in the results grid
In case a user attempts to circumvent the search page links and enter some document directly, again, check out for permissions.
Validation, validation, validation.
It should be very hard, near impossible, for me to run a query that makes no sense. ie, start date occurring after an end date.
Export a numerical dataset (even if it only has one numeric column - so just make it so by default) to CSV for import into Excel (people love this function, even if only 1% of users seem to use it with any regularity. Just ask yourself when's the last time you highlighted something for copy-n-paste. Would it have been easier to open a CSV?
Refinable searches (think Google's use of site: -). People who use the search utility a lot will appreciate this. People who don't won't know it's not there.
The ability to choose to display 1 records, 5 records, 100 records, 1000 records, etc. "Paging" I believe is what we most commonly call it ;).
You mentioned sortable grids. Somebody else mentioned auto-sum or auto-count. Those are good if (once again) you have largely numeric data. But those are almost report-oriented functions.
Hope this helps.
One thing you can do is have a drop down of most common searches in plain english. e.g. "High value sales in New York in last 5 days". This is the equivalent of user selecting an amount, the city, date ranges etc. done conveniently for them.
Another thing is to have multiple search criteria tabs based on perspective of the user. Like "sales search", "reporting search", "admin search" etc.
ALso consider limiting the number of entries retrieved in the search and allow users to do more narrow searches. This depends on the business needs however.
The most commonly used search option listed first and in a prominent location.
I think your requirements are good. Take a cue from Google. Google got it right. One text box where you type whatever you want, and your engine spits out the answers. Most folks will try this, and if the answers are good enough, then that is what they will use. In the back-end, you'll probably want to flatten all of the data into a big honkin' table and then index it or use a SQL query with "LIKE" in it.
However, you will probably want to allow the user to refine the search. For this, have a link to "Advanced Search" and use a form there to specify filter criteria. This lets the user zero in on the results if basic search is not good enough. For the results on th is page, you will certainly want to have sorting on key fields, but do it after you have produced the initial result set.
It depends on the content that you are searching for.. make it relevant :) Search always look easy but can be incredibly difficult to get right.
Not mentioned yet, but very important I think - a search that actually works. This item is often neglected and makes the rest a bit moot.
How would you create a database in Microsoft Access that is searchable only by certain fields and controlled by only a few (necessary) text boxes and check boxes on a form so it is easy to use - no difficult queries?
Example:
You have several text boxes and several corresponding check boxes on a form, and when the check box next to the text box is checked, the text box is enabled and you can then search by what is entered into said text box
(Actually I already know this, just playing stackoverflow jeopardy, where I ask a question I know the answer just to increase the world's coding knowledge! answer coming in about 5 mins)
My own solution is to add a "filter" control in the header part of the form for each of the columns I want to be able to filter on (usually all ...). Each time such a "filter" control is updated, a procedure will run to update the active filter of the form, using the "BuildCriteria" function available in Access VBA.
Thus, When I type "*cable*" in the "filter" at the top of the Purchase Order Description column, the "WHERE PODescription IS LIKE "*cable*" is automatically added to the MyForm.filter property ....
Some would object that filtering record source made of multiple underlying tables can become very tricky. That's right. So the best solution is according to me to always (I mean it!) use a flat table or a view ("SELECT" query in Access) as a record source for a form. This will make your life a lot easier!
Once you're convinced of this, you can even think of a small module that will automate the addition of "filter" controls and related procedures to your forms. You'll be on the right way for a real user-friendly client interface.
This is actually a pretty large topic, and fraught with all kinds of potential problems. Most intermediate to advanced books on Access will have some kind of section discussing "Query by Form," where you have an unbound form that allows the user to choose certain criteria, and that when executed, writes on-the-fly SQL to return the matching data.
In anything but a flat, single-table data structure, this is not a trivial task because the FROM clause of the SQL is dependent on the tables queried in the WHERE clause.
A few examples of some QBF forms from apps I've created for clients:
Querying 4 underlying tables
Querying a flat single table
Querying 3 underlying tables
Querying 6 underlying tables
Querying 2 underlying tables
The first one is driven by a class module that has properties that reflect the criteria selected in this form, and that has methods that write the FROM and WHERE clauses. This makes it extremely easy to add other fields (as long as those fields don't come from tables other than the ones already included).
The most complex part of the process is writing the FROM clause, as you have to have appropriate join types and include only the tables that are either in the SELECT clause or the WHERE clause. If you include anything else, you'll slow down your query a lot (especially if you have any outer joins).
But this is a big subject, and there is no magic bullet solution -- instead, something like this has to be created for each particular application. It's also important that you test it thoroughly with users, since what is completely clear and understandable to you, the developer, is often pretty darned mystifying to end users.
But that's a principle that doesn't just apply to QBF!
At start-up, you need to show a form and disable other menus etc. That way your user only ever sees your limited functionality and cannot directly open the tables etc.
This book excerpt, Real World Microsoft Access Database Protection and Security, should be enlightening.
For a question that vague, all that I can answer is open MS Access, and click the mouse a few times.
On second thought:
Use the "WhereCondition" argument of the "OpenForm" method
If the functionality is very limited and/or specialised then a SQL database is probably going to be overkill anyhow e.g. cache all combinations of the data locally, in memory even, and show one according to the checkboxes on the form. Previously you could have revoked permissions from the table and granted them only on VIEWs/PROCs that queried the data in the prescribed way, however security has been removed from MS Access 2007 so you can you now really stop users bypassing your simple app using, say, Excel and querying the data any way they like ...but then isn't that the point of an enterprise database? ;-)