[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.
Related
I have a table in SQL that I want to read into a DataGrid.
When I insert a new element I would like the DataGrid to update automatically.
Currently I manually do a SQL query and create a custom object that represents the objects in my SQL.
I am wondering whether I could use DataBinding but also maintain some control over how the data is read in? Because I'd like to have a local model to work with. Or is it just simpler to manually redownload the table after every insert?
Thanks
Yes of course. Using Entity framework, to pull the data, and then bind it to a control (or a complex form with many tabs) - and allowing the EF to do all the hard work for You is the way to go ...
Just imagine - if You have a complex model with a lot of controls, and when You hit save.. it just does that and generates as many inserts or updates for you.
with just one line of code. Context.SaveChanges :)
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?
Why excel? Well excel is what is used to import the player salaries.
Now I need the spreadsheet to do the following.
Create teams within salary cap.
Include/exclude specific player function
Build multiple lineups from a selected list of players within the cap
Can I do all of this with excel? or do I need to know excel vba as well?
Also which parts of excel or if necessary excel vba must I need to know to code such a thing? Also if someone could give me a short summary of the steps needed to hypothetically make such a thing it would be great. Thanks.
I'm posting this as a reply because it is too long for a comment window.
Just because Excel has a grid doesn't mean that it is fit for data storage and data handling, on the contrary.
What you typically want to do is create a transparent structure that guarantees the integrity of your data and that allows dynamic portability when needed one day.
Excel is meant to be a spreadsheet, people forget this all the time or they just avoid the topic: although Excel has a grid, doesn't mean that it is a good fit for reliable data storage. It is not even the least complex way of storing data, depending on the amount of VBA that you need to manage all these data and the gates that you unnecessarily open towards potential bugs.
This is why an RDBMS is what will fit your needs, in this case Access would be a good option as it preserves your data integrity if you get the table structure right and it executes a lot of tasks for you that you should otherwise need to program yourself to protect the integrity of your data.
Although you can perform SQL on spreadsheets too, note that Excel does NOT cover related tables (what you typically seem to need for building your teams and salary limits), so what many Excel programmers will typically do is to create their own code to make this cross-table data storage thing work.
Don't do this if the alternative is available and much more reliable and future-proof.
At first sight, it seems that you won't even need any VBA; I'm not sure of all the things you want to do, but my first impression is that you can manage everything with SQL syntax and stored queries in MS Access. You can import Excel sheets into Access if you get their format right so that should not be a problem.
Once your data is stored there, rest assured that you have made your life a lot easier.
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.
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? ;-)