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.
Continue reading “Build a Reporting Engine Using K2 SmartForms: The Interface”
My client has an older version of K2 blackpearl/K2 SmartForms, and is preparing to upgrade to the latest minor upgrade in version 4.
Here are my tips for upgrade prep.
Continue reading “Prepare to Upgrade Your K2 SmartForms Applications”
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.
Continue reading “Build a Reporting Engine Using K2 SmartForms: SQL, Part III”
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.
Continue reading “Build a Reporting Engine Using K2 SmartForms: SQL, Part I”
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.
Continue reading “Build a Reporting Engine using K2 SmartForms: Concept”
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.
Continue reading “Build a Reporting Engine using K2 SmartForms: Introduction and Terminology”
Given a SmartForm with the same item view attached to it three times, like rows: View A at top, View B in the center, and View C at bottom. Each view contains a series of controls, including a picker. Events on the view are wired such that the selections of the controls are recorded in a data label as each was made, So a dropdownlist control set to “I”, a radio button list with “am” selected, and a picker control set to “asleep” would give us a value of “I am asleep” in the data label.
I was seeing a peculiar behavior wherein the entire value of the data label in View A was being wiped out after the picker resolved, but the same combination of controls and values were working just fine in subsequent views. The same was also true if I skipped View A and used View B.
Continue reading “Cache the Picker’s Data to Avoid Problems with Events and Actions”