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.
Related
[Ms SQL]
I've got some data dense sql queries that I view the results of through the SSMS u/i in the datagrid.
The queries are saved as stored procedures that select multiple result sets.
I would like to be able to control the grid formatting a bit more (eg override column widths, decimal formats, right justify numbers, etc).
Is there an alternative to SSMS that would give me more control of the data presentation? It needs to be dynamic and not require a bunch of coding to display a new query (lots of sql work is ad hoc data exploration).
You can set up a data source in an Excel workbook, as long as the dataset isn't too huge.
https://blogs.office.com/2010/06/07/running-a-sql-stored-procedure-from-excel-no-vba/
You could also use SSRS, but Excel would be the fastest way to get going. SSRS is a little more work and probably not what you're looking for.
Edit - you said it returns multiple datasets. I'm not sure that Excel can handle that properly.
I suppose it depends entirely on what you're already comfortable with. Winforms + DataGridView controls inside TabControl objects are really easy to set up. Mostly you just bind the data to the DataGridView controls and they do the right thing based in data types. DataGridView has a virtual mode if your data is real freaking big (gives you control over paging, etc)..but this requires actual code. Old, easy and pretty robust if you're on windows UI...which is assumed given you're into the SSMS UI. Minimal C# or VB.Net required.
I'm not sure if this has been asked already but I'll take a shot and see what happens.
For my work we have been using Excel to generate all of our reports from instrument data. We recently implemented a Laboratory Information Management System that uses an SQL database and Crystal Reports to generate reports. I've had the fun (sarcasm) of recreating every report we run in Excel in Crystal Reports. There's one that I'm having the worst time to create. The report compares information for two samples. It compares information for one sample and then information from a replicate of that sample. I've tried every which way to bring in the data but it just repeats it for every record that's in the query. Here's a general idea of what I'm trying to accomplish:
I have two queries that bring in the same data. One query lists the original sample that I need and the second query lists the replicate that I need to use data from to calculate as well as every other sample. Essentially they're the exact same query. You can see below in the link.
Here is the query. http://tinypic.com/r/wiu591/8
For the report, I need to pull the data for two separate samples and compare it using crystal reports and perform calculations. Below is a picture of the report, the RER field is a calculated formula. I've brought in this query twice and before anyone asks "did you make links"....yes, I have and it just repeats the data because these are essentially two different records in two separate queries that are the same. I'm at a loss for ways to configure this.
Here is the gist on what the report needs to look like. I'm open if anyone can see a better way to redesign it. http://tinypic.com/r/123ayh1/8
NOTE: In the columns that say Sample and Replicate these ones are C10575 and C10575R and the data for each is below.
Any help would be awesome.
So the answer was to bring in two queries into the same view. I used the management studio to accomplish this. I brought in the two queries and didn't link them on the primary key which was the sample code. I linked on what these samples had in common. From there I did some fancy SQL'ing to sort out the samples I didn't need and presto. Got exactly what I need to throw into the crystal report and perform the calculations.
I'm looking for some ideas managing very large SQL queries in Oracle.
My employer is looking to build very wide reports ( 150 - 200 ) columns of data per report.
Each item is a sub-query or an element from a view. The data has to be real time, so DW style batch processing is not an option. We also don't use any BI tools , just a java app that generates Excel ( its a requirement to output data in Excel)
The query also contains unions as feeds from other systems.
The queries result in very large SQL ( about 1500 lines) that is very difficult to manage.
What strategies can I employ to make the work more manageable?
It is also not a performance problem. I was able to optimize the query to be very efficient , its mostly width of the query , managing 200 columns is a challenge in itself.
I deal with queries this length daily and here is some of what helps me out in manitaining them:
First alias every single one of the those columns. When you are building it you may know where each one came from but when it is time to make a change, it is really helpful to know exactly where each column came from. This applies to join conditions, group by and where conditions as well as the select columns.
Organize in easily understandable and testable chunks. I use temp tables to pull things that make sense together and so I can see the results before the final query while in test mode.
This brings me to test mode. If I have chunks of data, I design the proc with a test mode and then query individual temp tables when in test mode, so I can see where the data went wrong if there is a bug. Not sure how Oracle works but in SQL Server, I make this the last parameter and give it a default value, so that it doesn't need to be passed in by the application.
Consider logging the execution details and the values of passed in parameters and certainly log any error messages. This will help tremendously when you have to troubleshoot why this report that has functioned perfectly for six years doesn't work for this one user.
Put columns on a separate line for each one and do the same for where clauses. At times you may have to troublshoot by commenting out joins until you find the one that is causing the problem. It is easier if you can easily comment out the associated fields as well.
If you don't have a technical design document, then at least use comments to explain your thought process. You want to understand the whys not the hows in any comments. This stuff is hard to come back to later and understand even when you wrote it. Give your future self some help.
In developing from scratch, I put the select list in and then comment all but the first item. Then I build the query only until I get that value - testing until I am sure what I got was correct. Then I add the next one and whatever joins or where conditions I might need to get it. Test again making sure it is right. (Oops why did that go from 1000 records to 20000 when I added that? Hmm maybe there is something I need to handle there or is that right?) By adding only one thing at a time, you will find an error in the logic much faster and be much more confident of your results. It will also take you less time than trying to build a massive query in one go.
Finally, there is no substitute for understanding your data. There are plently of complex queries that work but do not give the correct answer. Know if you need an inner join or a left join. Know what where conditions you need to get the records you want. Know how to handle the records when you have a one-to-many relationship (this may require push back on the requirements); should you have 3 lines (one for each child record), or should you put that data in a comma delimited list or should you pick only one of the many records and have one line using aggregation. If the latter, what is the criteria for choosing the record you want to keep?
Without seeing the specifics of your problem, here are a couple of ideas that immediately come to mind:
If you are looking purely for management, I might suggest organizing your subqueries as a number of views and then referencing those views in your final query.
For performance on the other hand you may want to consider creating temp tables or even materialized views (which are fixed views) to break up the heavier parts of your process.
If your queries require an enormous amount of subquerying in order to gain usable data, you might need to rethink your database design and possibly create a number of datamarts to easily access reporting data. Think of these as mini-warehouses sans the multi-year trended data.
Finally, I know you said you don't use any BI tools but this problem certainly seems like one that might make sense by organizing your data into "cubes" or Business Object "universes". It might be worthwhile to at least entertain the cost of bringing on a BI tool vs. the programming hours to support the current setup.
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?
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? ;-)