Visual dBASE is now part of the InterBase Software Corporation. A subsidiary of Inprise Corp., this company already develops and market the InterBase relational database engine.
This new situation offers considerable opportunity for both products.
The InterBase relational database engine is renowned for its small footprint, simplified installation, reasonable pricing and good performance.
However, it lacks appropriate visual development tools, as well as an application developer community.
Visual dBASE brings exactly those missing points, together with an object-oriented application development language, two-way tools' designers and a good basis for Internet-ready extensions.
What can be done to turn the new brethren into one of the most successful set of products of the industry ?
Here are some simple ideas, as a contribution and food for thought.
The Visual dBASE developer community is in need for an upgrade path to the client/server world. While the current version 7 enables using relational database backends as well as "standard" native BDE table formats, upscaling is not as easy as may be expected.
Some of the data-related classes do not provide the same functionality for native tables and for InterBase tables -- index and filter functionality at rowset level come to mind. This should be completed.
It is the first and absolute necessity that the Visual dBASE developers get the same level of functionality for DBF and InterBase tables. This must be achieved whether implementation of such is made through the BDE or through a more direct integration with the InterBase engine.
This direct integration could be achieved by hooking to a DLL -- as has been done for Delphi -- but the nature o the Visual dBASE development environment requires a transparent integration. The use of data-related components must be possible in a similar way for BDE-based or InterBase-based data sources.
Also, deployment of the InterBase engine and associated configuration parameters must be handled by Visual dBASE in a similar way as for BDE-based applications. The tailored version of InstallShield provided with Visual dBASE should be upgraded to handle such needs, as well as network/client install situations.
The level 7 DBF tables have introduced the concepts of data dictionary and validation rules at database (table) level to the Visual dBASE developer. When one starts to implement this functionality in its application development work, he will not want to do without it and get back to the old world where the rules had to be duplicated in every application using the same data.
The developer must then be able to use the same set of data-based rules both for DBF tables and InterBase tables. More importantly, he must have the possibility to migrate the dictionary and rules from one data environment to the other.
Storing rules at the database level instead of the application level requires for programming these rules in the database engine. Stored procedures are available in InterBase, together with the appropriate trigger mechanism.
Yes, but to create and use these stored procedures, the Visual dBASE developer will have to learn yet another programming language.
While SQL is a must as a data manipulation language, its proprietary extensions as a programming language is far from being justified where a powerful object-oriented language is already available to the Visual dBASE developer.
One can foresee several directions to provide for a possibility to use the Visual dBASE language in InterBase stored procedures :
1. Integrate the Visual dBASE virtual machine together with the InterBase engine on the server side.
2. Provide for a mean to trigger Visual dBASE language procedures in server-side executables, acting as stored procedures.
3. The Visual dBASE server-side program can be implemented as an ActiveX. Its functions (methods) could then be called by means of the InterBase triggers.
Creating ActiveX components out of Visual dBASE forms and classes is currently possible only by using a third-party tool -- such as JazzAge ActiveX Factory.
Integrating such functionality in the future Visual dBASE IDE not only would solve the need for server-side components in an elegant way, it would as well open the door of component-based distributed computing to the Visual dBASE developers.
Some nice-to-have features include the semi-automated surfacing of properties, methods and events between the server-side (remote) and the client-side parts of a component couple.
It can also enable easier programming of one-to-many components for multi-tiered applications, where part of the business logic can be handled in server-side components, or in standalone business components.
Providing for server-side memory-resident executables would also open more widely the doors of the Internet and intranets to Visual dBASE developers.
As a database-centric visual object-oriented development environment, Visual dBASE is very well suited for transaction-based applications using thin-clients over the Web.
Currently, building Web-based server programs generating dynamic HTML pages through a CGI-Bin gateway is possible using the Visual dBASE WebTools.
However, some features are missing to provide for a competitive Web-based development environment.
- CSS Cascading style-sheet support in the generated HTML pages
- Web-site management capabilities, or easy interfacing with other adequate existing tools.
- Easy integration with leading vendors HTTP servers API -- including MS-ISAPI and NSAPI -- in addition to CGI.
- Tools and sample applications for e-commerce, including secure transaction support and payment through leading financial networks.
In short, look at what HaHtsite and Allaire are providing in that respect. Give us similar features and Visual dBASE will be the best development tool for Web-based applications around.
Globalization is the buzzword of the day.
However, there is also a reality that must be faced behind the word. Any piece of sotware built nowadays must take into account its possible use in different cultural and language environments.
To take this basic fact into account means providing the appropriate tools for the job in the development environment itself.
Internationalization and localization are the traditional means for the task. However, shrinking resources have resulted in abandoning localization for some markets for Visual dBASE version 7. You can see the result of such short-sighted strategy on the sales results for this version in the countries concerned.
However, there is more in this issue than maket share in some individual countries. The question is simple to ask : do you believe any database development product can survive while addressing the English speaking market only ? Is the question really different if you only have a couple more localized versions available in addition to the English speaking version ?
The paper Meeting the Open Markets Challenge proposes a multi-level strategy to address this matter.in a cost-effective manner in the European Union. While written before the release of Visual dBASE version 7, this paper still proposes valid ways to address the issue at hand.
You are in a much better position to achieve such an efficient move than before, as the InterBase Software Corporation is not bound by the local short-sighted politics of many individual country-based subsidiaries.
Adding new features is always nice to have. However, more important than adding gadgets and announce features the Microsoft way, any provided functionality must be fully functional and operational.
In other words it is better to postpone features when needed in favor of securing and fine tuning of the functionality at hand. Better no feature than a GPF-enabled gadget.
Polishing the current IDE certainly is a priority, before any new functionality is added.
This really is more of a marketing question.
The answer provided with Visual dBASE version 7 has been to move away from the end-user and concentrate on the developer. However, we must remember that in many companies dBASE was choosed both as an end-user query and reporting tool as well as a development platform. When facing the migration dilemma they have to choose between going to the 16-bit version 5.6, or else, to competing products.
The question can be debated whether it is advisable or not to dedicate resources to reintroducing more end-user features. It is certainly not the top item in the list, but it could also be a compelling reason for choice for some clients.
One other way of addressing this issue could also be by way of bundling an optional third party query and reporting tool, which would install automatically and integrate smoothly. Or else, making sure such a tool is available through special agreements.
The third party market for Visual dBASE is not very strong. One reason for this situation comes from the strength of the Visual dBASE object-oriented language and development environment.
Another reason -- closely related to the former one -- is that the dBASE developers have a long habit of handling their various tools needs by themselves.
However, an intelligent negotiation with vendors of some appropriate tools can satisfy converging interests. It may also lead to provide for adequate improved interfacing as well as possible bundling with Visual dBASE and InterBase. The following possibilities come to mind :
- Application documentation tools -- integrated in the Project Explorer -- can bring the final quality touch to the future version of Visual dBASE and confirm its role as a leading business application development environment.
- Web-site analysis and management tools can be bundled with the professional version and client/server versions.
- An appropriate data modeling CASE tool is needed. Providing the specifications of SQL DDL language for DBF (BDE) and InterBase tables to vendors such as the makers of xCase could pave the way for the use of a performing and reasonably priced tool for Visual dBASE/InterBase developers.
- If native ActiveX generation is not provided in Visual dBASE, an ActiveX workshop tool such as the JazzAge ActiveX Factory can be bundled with the professional or client/server version of the product.
A question remains : must the name of either product be changed to give a strong signal about the new orientation for the two products ?
Some opinions have been expressed in favor of displaying in a more radical way the new OOP nature and web orientation of the current and future Visual dBASE incarnations. As far as I am concerned, I do have my preferences: Visual InterBase for the development environment, keep InterBase for the engine and use dInterBase for the marketing moto. However, this remains an open question that I will leave to the marketing gurus.
Whatever the outcome, even if a change in name is decided, I strongly believe that the word "dBASE" has to show up on the box and specs' sheets one way or another, even if only in a subtitle instead of the product name.
We all know of hundreds of business sites where old dBASE applications are still running. Most of them do not care about the advertisements or about the computer magazines' articles and benchmarks until they have to face a decision for an upgrade. When this time comes, they must be able to find the successor of the good old dBASE in their computer store or on the Web.
To ascertain the new nature of the future Visual dBASE, an InterBase engine should be included with all versions of the product.
The full version -- bundled with a given number of users -- can of course be included in the client/server version. The Professional version of Visual dBASE must also come with it, even if it includes a limited number of users, for development purpose. A scaled down version could also be included with a low cost standard version of Visual dBASE (no access to stored procedures, triggers, etc.).
This certainly is the beginning of a new era for the Visual dBASE and InterBase developer community. I can't stop my mind from imagining all the amazing applications we will be able to create with the future versions of these products. I am sure we must have found the right nest for the tools to make our dreams come true !
François Ghoche - Aug-Oct 1998