XBase & ISAM

Several popular legacy ISAM and XBase database engines exist that were originally developed in the late 1980's and early 1990's to provide support for managing legacy DBF, FoxPro, Clipper and dBASE files. Some were or some proprietary version of the DBF file format.

As was Cobol in the 1970's, XBase was the premier development platform of the 1980's and 1990's. XBase technology introduced several good database concepts such as Rushmore technology and high-speed indexes with user defined functions. But after so many years these file types are now showing their age, especially under the new world of managed development with .NET. These XBase products will remain useful only if you must support the following:

  • Manage legacy XBase data files
  • Support multiple legacy platforms (e.g. Novell, Win16 and Win32)

Paradox and BDE

Paradox presents developers with three unique problems:

  • Notorious for losing data inexplicably through its caching mechanism
  • Requires the BDE (Borland Database Engine) to be installed and configured on each work station
  • The BDE footprint is ~10MB in size

The BDE is Borland's database connectivity technology that consists of multiple technologies and products combined into one. The BDE provides connectivity technology to access various databases plus it includes the actual data engines for dBASE and Paradox. Borland has deprecated the BDE several years ago.

The world is making a big transition to .NET, which presents XBase and Paradox developers the perfect incentive to finally break from old database technology and start using a modern RDBMS that was specifically designed to take full advantage of the powerful .NET platform.

XBase was not designed for .Net

None of the mentioned XBase products were designed specifically for .NET. More importantly, these products typically have proprietary support for several platforms such as Novell, Linux and UNIX in addition to .NET, which is a good thing if you need it, but is a waste of your vendors resources otherwise. Marshaling of data, COM context problems, and the GC cause a lot of performance and memory problems for unmanaged providers in the .Net environment.

Providing cross-platform and multi-tool support does not benefit .NET developers that are developing NET applications. Providing this additional cross-platform support forces these vendors to invest precious time away from improving their .NET implementations. Instead, these XBase vendors must spend time on keeping all editions of their software synchronized and backwards compatible with features and databases that are often archaic.

Each time these XBase vendors introduce a single new feature into their core database product, that new feature must be propagated to several other editions of their products, then also to each platform they support, then finally they must test all of these implementations before their database product can actually be released to the public. All this effort and multi-platform testing is incredibly time consuming. This type of environment does not foster new technology and ultimately does not benefit developers that are focused on building .NET applications.

Because of this unfocused, multi-platform, multi-language support these database solutions have experienced few improvements over the years. Furthermore, their existing customers continue to demand attention and support for their legacy needs. Because of all these factors, we see the future for these vendors in the .NET world to be limited. Ultimately, these XBase engines have one purpose: to provide legacy support for managing old, XBase DBF data files.

VistaDB was designed for .Net and managed runtimes

We have extensive first-hand experience of the problems and difficulties in pursuing this splintered managed and unmanaged development strategy. That is, to create multiple editions of a core database product and try to support multiple development tools.

It is very difficult to do successfully and ultimately, the core product and support suffers. We realized that this direction would not allow us to build and grow a quality database engine for the long-term. We decided to drop all of our unmanaged code and focus entirely on .Net database efforts in order to better serve our customers needs.

We built VistaDB specifically for .NET using our experience with serverless database technology as the foundation of our work. VistaDB is 100% managed database written in C# specifically for .Net developers.