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?
Related
I am not proficient in either macro scripting in excel or scripting in general. I have a general sense of syntax and language formatting so I'm not necessarily going in empty handed with trying to program my owns scripts and I'm leaning this way due to the unique scenario I will be using the spreadsheet.
Essentially I'm wanting to track some data pertaining to slots for a pet project. What I desire is a "start" button that prompts which column I would like my "session" to start in, moves the selected cell to that column and prompts for a starting balance and fills it into the appropriate column; then there are a choice of buttons from which one that pertains to each of my bet options (there are 4) and that will fill in a column net to my balance with the appropriate amount as well as update the balance column to the next row. Lastly I would like to have 6(button) options for certain indicators I would like to track.
All of this I would like to run off of keyboard hotkeys if possible. Ultimately I'm mainly asking for resources since most of the "tutorials" show how to make a button, and some sense of hello world macros, but I'm mainly needing to find page navigation macros, input, take existing data, and append or modify that data with current variables.
-Thank You for any advice or resources and for your guys' time :D
I'm currently trying macro recording but it seems a little but specific to copy pasta situations and not so much the calculation, though small, but redundant that I could optimize with better scripting. I'm also finding that most of the buttons output to a text document outside of libre calc.
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').
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.
Is there a quick and easy way to make a VB.NET user interface for managing the data in a normalized DataSet?
I know that is a very subjective question, so let me explain. For a brief period early in my career, I used to create user interfaces in Microsoft Access. I developed a simple, but very effective approach to user interface design. Here are some details of that approach:
Create one form per table. Put on
each form all controls necessary to
completely manage one row in the
table.
Use combo boxes for
foreign-key columns.
Give the user a
standard way to add rows and delete
rows.
Use Apply and Undo buttons.
Let
the user navigate from one row to
another with a list box.
Provide a
search box and filter options for
more efficient navigation.
Let the
user double-click on controls
representing foreign-key columns to
quickly navigate from one form to
another.
Make the state of each form
persistent (so the user always
returns to the last navigation point)
etc.
Simple, right? I found that Access encouraged this approach. It has many built-in features that make this kind of UI easy. For instance, creating a combo box to represent a foreign key relationship takes about 10 seconds.
Well, I haven't worked in Access for a while. A couple of years ago, however, I was hired to write an application in VB.NET on the NET 2.0 framework. To get a data management user interface up and running quickly, I used my Access experience to write a quick & easy prototype in Access -- that took me about one week. Then I hired a programmer to implement that same UI in VB.NET. What a nightmare! We've been working on that implementation for a year, and I'm still very unsatisfied with the results. Some of the problems we are having:
Apply and Undo buttons don't work quite right. We can't find an event that tells us when the form is "dirty" (thus making Apply and Undo relevant).
Navigation from row to row and from form to form requires surprisingly complicated code. I get the impression that we are fighting against NET's binding features, not working with them the way they were intended to be used.
The NET controls seem buggy. For instance, when the user types a value into a combo box (as opposed to choosing it from the drop down), it doesn't trigger the SelectedValueChanged event.
We seem to be repeating a lot of information. For instance, the DataSet knows there is a relationship between the columns in two tables, but we must nevertheless effectively repeat the details of that relationship when we program the combo boxes, binding, navigtation features, etc.
We still don't have good solutions for the filter and search features. There are lots of little details to work out. (For instance, what if you choose a filter that doesn't include the currently displayed row?)
We are writing many helper functions and classes to simplify the work, and I can't figure out why that effort hasn't already been done by others -- I'm certain we are reinventing the wheel.
etc.
By themselves, none of the above are a big deal -- there are effective solutions to each one. Taken together, however, these problems are making my UI development go much slower than expected.
In an ideal world, I should be able to create a small amount of code relevant to my specific data model (for instance, one user control per table establishing the layout and logic relevant to the rows in that table) then integrate that code into a template which interprets the data model and handles everything else -- navigation, adding and deleting, apply and undo, search and filter, etc.
Thus, my question: Is there anything out there which makes this type of UI development easier?
I've searched the web for various combinations of "generic forms", "UI templates", "data managment forms", etc., but I haven't found anything on topic. Perhaps I just don't know the buzzwords. Is there a specific name for this type of UI development task?
Create UCs for each table. Drop a grid control onto the UC and bind it to the tables dataset using VS's wizard. Select the options that allow for insert, update, delete. Each row on the grid will have those buttons/actions automatically added for you.
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? ;-)