This is to state some facts and principles that might help us design a good database front end. This is meant for discussion.
Chris Lee visualized and J Merrill built the first implementation of a database front end whereby one could program using SQL without being concerned about what version of SQL one is using. Softmed uses Microsoft SQL Server so it has only been tested and debugged for SQL Server. This application is called "STS" for "SQL Table Suite" and it is built on Visual Studio (C++). It also requires LinkPro (32 bit) which costs $750 ($550 for upgrade) and uses the ODBC interface. J cautions that STS requires a large learning curve.
According to J, MS has a lite version of SQL Server called "MSDE" (Microsoft Data Engine) which is free (with license of one of Visual Basic, Visual Studio, C++, etc.) and adequate for handling a small number of simultaneous users. Microsoft's intent is that this allows for application development and assumes that as apps get enterprise use the user will upgrade to SQL Server. All code developed for MSDE will run without modification on SQL Server.
Carl presently stores data in apl .sf files in a database structure he created (call it "dv"). Maintenance programs use "dv" syntax for accessing data which might be revised to use syntax that will access the same data from a SQL database. Perhaps the new syntax can be made to work equally well with the old "dv" structure or the new SQL structure. Then, during testing for conversion, one can throw a boolean switch to access either the apl database or the SQL database.
Chris Lee, Eric Landau, and J Merrill are exceptional among programmers in that they are all highly committed to creating and using high level objects. (Eric Lescasse and I are the only other APL programmers in my awareness who share this commitment.) Chris, Eric, and J's work shows up at Softmed. In our discussions, it appears that Softmed objects are an intense labyrinth of objects that require a major learning curve and programming commitment for a new project to get on board. It appears to me that this is not true of Lescasse Objects. Lescasse Objects are built upon a few functions common to all objects, but most objects can be used independantly of other objects. This means that an object oriented programming effort using Lescasse objects can be viewed as many smaller projects more easily than the Softmed objects. This might mean that (in a situation where functions for a certain task don't exist) it is difficult to get to raw data with Softmed utilities while Lescasse Objects do not prevent one from working with raw data or from using other low level approaches where they are desired.
As we are contemplating an object oriented approach for "qkw shareware", it might be important to hold as a design criteria that we should not become invested in such a labyrinth of object structure that we are prevented from using quick and dirty approaches when they are needed.
"Echo" seems to have relevance to our db front end.