I live in Texas. For the past few days, we’ve been getting storms — some violent — at around 3 AM. If the storms are bad enough, I’ll have a headache all day — and I don’t mean from the barometric pressure.
I’m working on re-creating a SmartForms application for a client — which was already in progress when I took over for another engineer — when I bumped into the exception described in the the title. This application was deployed from another environment.
Where’s the problem?
I think it’s fair to say that most of us in this industry at least started out taking over someone else’s project. The original developer left long before you got there, leaving you to figure out what’s what.
Some of us are still in that position, or find ourselves back in that position at some point. So if you can take the time to inventory all of your SmartForms objects at the start, you can let your shiny new object relational management (ORM) database do a lot of your grunt work for you later on.
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.
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.
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.