Several years ago we used Sequiter’s Codebase tools to allow "customer A" to talk (from some Kman apps they had) to Fox tables in an SBT accounting system.

This work was later used as a starting point for migrating "customer B"’s order entry system from one that read Kman tables to one that reads Visual Fox tables. Using our previous experience with Sequiter, we built a low-level C layer on Sequiter’s functions that could talk to either Kman or Visual Fox with the same interface, and above that a layer that connected it to the Kman language. This allows legacy Kman apps to talk interchangeably to Kman or Fox through the same data access calls in Kman.

Now "customer A" wants a new VB 6 application, but must be able to talk to some legacy Kman tables as well as newer types of data. To solve this problem, we plan to combine a VB/data access foundation already in production in another department, but modify the persist layer to read Kman as needed read/write Kman instead of SQL Server. Kman’s native data access API is full of pointer references which are much more difficult to manage in a VB environment than in C/C++, so to simplify the VB persist layer coding, we will use the Sequiter C layer developed in b above as a way to build a set of functions available to VB 6.0 for talking to Kman tables.

Since the above work was completed, another business needed to migrate from legacy Kman tables to FOX. One of us applied the same techniques to accomplish that migration in a much shorter time, but in the process recompiled the Sequiter layer as a 16-bit module (b) above was 32-bit only), so that now we can migrate 16-bit Kman apps without the customer needing to purchase expensive 32-bit Kman-to-Guru upgrades.

We will most likely encounter other customers in the future with legacy Kman apps, but who are building GUI windows apps today, and need to use the tools we have developed above to help them transition out of Kman and into modern, well-supported tools.