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.
I’m supporting an application that has a large number of rules inside the SmartForms. My task is to change some text. Instead of combing through all of the views and forms to find the text I need to change, I thought I’d try to work a little smarter.
We have a demo instance and a production instance of a particular workflow. I got a frantic call from one of the business people telling me that she didn’t have access to all of the roles in the demo instance that she does in production.
I verified this and attempted to correct it by assigning her to the various additional roles. When I asked her to close her browser, then re-open it and navigate back to her worklist, no change had been made.
Continue reading
Start Rule 