On Friday, July 15, 2022, we were forced to bid an untimely farewell to a dear mentor, colleague, and friend. Dave Harmacek was a veteran in the Revelation Software community for 40 years. Normally I would say he has forgotten more than most developers even know, but Dave was very methodical and stored everything he ever learned in Evernote. Consequently, there was very little that he didn’t know or couldn’t retrieve when needed. Dave was always quick to share his knowledge with anyone who had a question. He was a talented programmer, eager teacher, and very generous with his time.
I came to know him very well through the online platforms that our humble cadre of developers joined in. When Revelation Software began to sponsor semi-annual User Group Conferences, I got to know and appreciate him even more. He endeared himself to me after one conference when my wife told me, “I like Dave, he is one of the few people at this conference who talks to me about things other than programming!”
Interestingly enough, even though we would often help each other on technical issues over these past many years, we only began to collaborate on projects in 2020. I now look back and appreciate our brief partnership that much more. It was a pleasure to work together with Dave doing what we both love: helping our clients achieve their business goals.
Farewell to a legend. You have been and will continue to be missed.
Wow…it’s been almost three years to the date since we announced the general availability of the SRP HTTP Framework. Don’t let the time gap fool you. This product has continued to go through ongoing updates and enhancements with new versions coming out on average every 4 months. Our only excuse for not posting additional notices to our blog site is that we’ve remained very busy building and supporting RESTful API solutions for our clients. It has been quite satisfying to see the diverse ways that we have been able to integrate OpenInsight’s flexible data engine, robust business rules language, and universally recognized and respected REST APIs.
Perhaps one of the most powerful yet underutilized features of the Banded Report Writer is the ability to pull data from programmatic data sources. As the name suggests, developers can define data sources using BASIC+ stored procedures as an alternative to the traditional method of pulling data from database tables. Conceptually, this should be very familiar to Revelation developers as this takes the concept of a calculated column (aka symbolic field) and elevates it to an entire table. In fact, our team takes its cue from this similarity and uses virtual table interchangeably with programmatic data source. If you are unfamiliar with programmatic data sources, read on for an explanation of how they are configured.
Recently a client asked us if there was a way to call OpenInsight externally using a URL syntax. Initially we were confused because this client was already using the OECGI to enable HTTP access (i.e., via a URL syntax) into his application. After a few more email exchanges we came to understand that the client was interested in creating a custom URI Scheme for OpenInsight like so:
Over the past couple of years, SRP has been quite busy working with other development teams on projects requiring integration between OpenInsight and SQL database servers. In most cases, these systems already had interfaces designed around ODBC. While functional, we proposed converting these ODBC processes to ActiveX Data Objects (ADO) to improve performance, reliability, and ease of maintenance. While ADO is certainly not new and has been promoted within the Revelation community for many years, we’ve met a number of developers who are still unfamiliar with it. We concluded this is mainly due to two reasons: 1.) adherence to the adage, “if it ain’t broke then don’t fix it”, and 2.) general confusion about how to make it work. This article hopes to clear up any uncertainty regarding ADO and perhaps encourage others to give it another look.
As a provider of two framework products for OpenInsight, we recommend our customers create a dedicated application (e.g., FRAMEWORKS) to maintain the original framework entities. Then the business (or commercial product) application should be created to inherit from this application rather than directly from the Default Inheritance (i.e., SYSPROG). This is easy enough when the local application has not yet been created. However, there are times when the child application already exists. This brings up the question, “Is there an easier way to change an application’s parent without having to back up the local app, delete it, and then recreate it with new inheritance?” Indeed there is.
It is not a matter of if it will happen, but when it will happen: a system will require some data to be restored. Like any restoration project, there are numerous ways to approach this task and typically the best method will depend upon the scope of the restoration. In our world, this can range from restoring an entire volume of database tables to a select group of database rows. Recently, one of our enterprise clients ran into this very problem when pre-existing business logic simply wiped out a number of critical records. This situation quickly became an urgent priority since it was directly impacting production on the factory floor. Fortunately, since only a few rows were affected the effort required to recover the data from a backup was rather simple.