My client was looking for a way to export a list produced by a reporting engine to a Microsoft Excel® spreadsheet file (.xlsx). Other applications in the company have made use of an Excel Export control, so I thought I’d better figure the thing out.
This post is the sixth and final installment in the Build a Reporting Engine Using K2 SmartForms series.
In previous posts, I talked about some aspects of the T-SQL used to support the engine, and touched time and again on how the actual job of the interface is to build a SQL
WHERE clause to append to a
SELECT statement and execute to return data to a list.
Today I’ll talk a bit about the interface.
This post is the fifth installment in the Build a Reporting Engine Using K2 SmartForms series.
In the previous post I shared some thoughts about database functions that would make life easier when building your reporting engine. In this post, I thought I would wrap up the data layer discussion with a word or two about stored procedures.
This post is the fourth installment in the Build a Reporting Engine Using K2 SmartForms series.
In the previous post I shared some information you might consider when designing your data source and some of the database objects that will directly support the reporting engine — specifically, tables and views. In this installment I thought I’d offer some insight into functions I used when building my reporting engine.
This post is the third installment in the Build a Reporting Engine Using K2 SmartForms series.
Through reading the previous related posts, you should understand that the secret sauce to this whole engine is the generation of a
WHERE clause that gets matched to a
SELECT statement to form a T-SQL query. So I thought I’d offer some thoughts on how to structure your database objects to support the reporting engine.
This post is the second installment in the Build a Reporting Engine Using K2 SmartForms series.
The concept behind the reporting engine is simple: put the querying power of Transact-SQL (T-SQL) into the hands of business users through a simplified and intuitive interface.
I can’t recall the last time I’d been this excited about building a new feature.
My client has a high-touch, high-visibility application — and I mean “high-touch” more in the sense that a lot of people use it, rather than it gets used often (quantity as opposed to duration, I guess). At the top of my clients’ Christmas list this year was a new feature for building and persisting reports that can be used to monitor the progress of work items through their process.
I wanted to build them a reporting engine that was flexible enough to provide insight from multiple data sources, and with an interface that was as familiar and intuitive as possible.