||This is the technical paper from a talk given at the 12th Annual Borland Developer's Conference
By Nick Gorham Easysoft Ltd.
Note: No portion of this paper may be distributed or reproduced by any means, or in any form, without the author's and/or Borland's prior written permission.
As many of you will be aware InterBase is a high performance, relational database management system, providing SQL92 conformance, good transaction model, extensible user defined functions, and powerful stored procedures. However as I am sure you are all more than aware, all that's of no use, if you can't connect to and provide data for your application, web server or development system. Luckily, the connectivity options available to potential user of InterBase are legion, in fact to a new recruit, the number and range of options may be somewhat daunting. Compared to many of the other relational databases that are available, InterBase appears to be one of the simplest to install, and by using the available console and command line tools, connect, and retrieve data via simple SQL statements. This talk is aimed at both the new and existing user of InterBase who may be in this position. Having installed InterBase and verified its running, then having created a few test tables and inserted some data using either IBConsole or isql, you are now wondering what to do next.
It is not my intention, in this talk, to cover connection via IBX, BDE or IBObjects, these methods have been very well documented elsewhere and the audience may well have more experience of these methods than I do. Instead it is my intention to investigate the many other options available to the programmer or system designer, which while they may be industry standards in their own right, may not in the past, have been associated with InterBase. I will cover general connections methods including ODBC, JDBC and Perl DBI drivers, and also discuss how InterBase data may be presented via the World Wide Web, using servers such as Apache and Microsoft's Internet Information Server, using active server pages, ADO, PHP, ColdFusion, and iHTML to name a few.
Before continuing with general connectivity issues, I should take a few moments to introduce both myself, and Easysoft the company who are generous enough to pay me to program computers during the day. I am responsible for the Easysoft ODBC Driver for InterBase, which has been adopted by Borland, for their certified release of InterBase 6. By responsible, I mean that having written the driver, I also provide second line support, behind the Easysoft support desk team. I am also involved in any future developments that may take place with InterBase and Easysoft. Many of you who follow, the several InterBase, mailing lists and newsgroups, may have seen my postings, which I hope have been regarded as informative, and with luck, correct. I am also the current leader of the unixODBC open source project, about which I will talk in greater detail a little later.
Easysoft are a software company, located in the North of England, which at the time of writing employs around 30 people. We specialize in data access middleware, and have been writing ODBC drivers and providing data access to legacy data for over 8 years. We therefore predate the emergence of middleware as a term, which now seems to have fallen into the realm of hype, and public relations, instead of an active part of the industry. We are also justly proud to have received one of the most prestigious awards in the United Kingdom, namely the Queens award for industry, for the year 2001 to 2002.
Anyway that's enough about myself, now on to InterBase, and how to connect to it.
General InterBase connectivity issues
I am sure that many of you will have seen this diagram on the InterBase section of the Borland web site. It shows many of the topics we will be discussing and how they fit together. It also shows a key item in InterBase connectivity, namely GDS32.DLL, or on Unix platforms libgds.so (or variations on the name, normally including .so, gds and lib in some combination). This library irrespective of its name provides the basic InterBase API. This is the collection of function calls normally beginning with isc, which provides the functionality required for all (with one exception, I will mention later) the connection methods to InterBase.
It is my intention to avoid wherever possible in this talk, the introduction of actual coding examples, mainly because, they can become very tedious to read aloud, and equally irritating to listen to. But also because they lead directly to the religious and national debate how to pronounce the character that precedes the word "define" in the 'C' language, and other issues of interest to programmers but not particularly relevant to the purpose on hand.
Not withstanding this, we should consider briefly the InterBase API call isc_attach_database, this provides for the actual connection between the application calling the API, and the database itself. The important argument here (again avoiding code as far as possible), is the third one, this is a string containing the name of the database we wish our application to connect with. In the simplest use the database string contains the path, in the syntax of the local file system of the InterBase database file. So for example on Windows, it may be c:test.gdb. This will (assuming the call succeeds) provide a local connection to the database, and the GDS library will provide the services of the database management system to the calling process. The fact that it is within the process space of the calling process can be important, as we will see later. This is the simple way of connecting to an InterBase database. However it is not the only way. It is alse possible to prefix the database string with the name of a server computer that contains the InterBase database file within its own file system, remote (and perhaps not directly accessible) from the calling system. This will create a client-server connection to the remote system, with the GDS library providing transparent network communication to the remote server. Now in this situation the process accessing the database file is not the same as the process making the call. We will discuss the importance of this later.
Many of you will be familiar, with Open DataBase Connectivity, as this has been a central feature of the data access world on Windows for several years now. Just about any Window application that concerns itself with accessing relational data will provide an interface to ODBC. I will refrain from repeating the names of example applications, as I am certain that unless you still use MS DOS 3 as your main operating system, you will yourself have used one or more by now. ODBC has suffered from quite a lot of "bad press" in its time, some, but by no means all deserved, and it still is considered by many, to have the Redmond sword of Damocles hanging over it, though I suspect the retaining thread is still somewhat more robust, than some would have us believe.
ODBC first appeared in the early nineties, in its original 1.0 form. At that time documentation, while available, was somewhat "subject to change". In fact during its development, the early Easysoft driver used Microsoft Access, as something of a reference platform, it being then the only available application that made use of ODBC. And in fact, for us ODBC conformance meant for some time, "it works with Access". As time passed, more applications appeared, along with drivers of varying quality for many popular databases. At this time ODBC was the "golden boy" of Microsoft data access, and received not just the support of the Microsoft development team, but also of their marketing arm. Many long-time Borland users may remember the conflict between ODBC and at the time the more advanced options available from Borland. I will resist the temptation to revisit these marketing wars, but I suspect many of the long lasting objections to ODBC, stem from those times. Many of the drivers at that time, had very poor performance, and were generally unreliable. This may have been the result of a combination of the lack of experience on the part of the driver writers, and also by application writers not making the most of the, at that time, new and unfamiliar API. It may be age and cynicism on my part, but I also suspect that more than one database vendor may not have applied the same level of optimization to their ODBC driver, as they did to their own propriety interface API. I will leave other to speculate why that may have been.
It may not be obvious to many of the younger members of the audience, but at the time ODBC first appeared, the data access market was in a nightmare situation for programmers, each database had its own interface API, all different, all claiming to be better, faster, easier, or even perhaps harder. Remember job security, if the API is hard to learn, then its harder to find replacement coders, and think of the income from training courses... It was into this environment that ODBC appeared, and I suspect without the help of the Microsoft machine, it may not have survived to this day.
Because ODBC was designed, to provide less of an abstraction layer to a database, but more of a common low level interface, it contains many duplications of functions, this can mean that there are several ways to perform the same operation, some better implemented in one driver than the next, and some not implemented at all. It does however provide a mechanism for a application to determine just what features are provided, and this allows the application to alter its operation to match.
ODBC 2.0 appeared soon after, providing several additional features, most notably the provision for asynchronous operation. This version of ODBC soon became a standard for application writers, and during this period the quality of the available drivers increased, and not just those from Microsoft. The number of applications using ODBC also increased considerably, and ODBC became the API of choice for many programmers. It still provided for more than one way to do the same thing, and even more options and extensions were added, as more and more database vendors rushed to add support for their own proprietary features. The success of ODBC 2.0, and the soon to follow 2.5, can be seen by the number of applications still using this version of the API
Before bringing ODBC on Windows up to date, it is worth briefly discussing the structure of an application using ODBC.
ODBC applications never directly connect to ODBC drivers, the application writer links the application with the ODBC Driver Manager. This is a set of libraries that provide the full ODBC API, and are responsible for run time loading of the actual driver or drivers to provide access to the target database. It is this run time loading that enables the application writer to produce applications in the absence of the final driver; the driver manager handles and controls all interaction between the application and the actual driver. One of the most important functions of the driver manager is the replacement of the called function with the closest match in the target driver. It was with the introduction of ODBC 3 and above that this mapping process has became a central feature of ODBC.
ODBC 3.0 and the soon to follow 3.5, and beyond, marked a major change. Microsoft introduced several new concepts from the X Open CLI database access API, which itself stemmed from the same roots as ODBC. In fact Microsoft aligned ODBC 3.0 with the CLI standard, so the difference between an ODBC driver and a CLI one, became insignificant in practice. Microsoft also handed ODBC to the X Open group, though it is perhaps not a coincidence; that after this transfer, the new Microsoft opinion became that ODBC was a spent force, due to be replaced, maybe within weeks, by new, and vastly superior data access methods. This replacement may happen, but at this moment, ODBC 3 has been in existence for over 5 years, and shows no practical sign of going away.
One of the stated goals of ODBC 3 was that all existing ODBC 1 and 2 applications would continue to operate as before, while developers re-coded their applications to use the ODBC 3 API methods. This was achieved by allowing the driver manager to map ODBC 2 calls from application into ODBC 3 calls in the drivers, and the opposite for ODBC 3 applications to ODBC 2 drivers. With ODBC 3.51 Unicode operation also became available, and again it was the responsibility of the driver manager to handle any conversion between Unicode and ANSI applications and drivers.
So that's where ODBC is on Windows at the moment, in many ways flawed, but still very workable, with drivers available for just about every popular relational database, and many unpopular ones. However there is one catch to all of this, up to now, its Windows only.
After the introduction of ODBC as a Windows data access API, the next obvious question is, why just Windows? There is nothing within ODBC that ties it to a Microsoft operating system; in fact if one browses the header files provided by Microsoft as part of the ODBC software development kit, you will see that some (little) provision is in place for non-windows implementations.
Before discussing the current state of ODBC on non-windows platforms, it may be worthwhile, quickly covering its recent history. Soon after Microsoft first released ODBC 1.0, a software company Visigenix, licensed, the driver manager, cursor library and related bits and pieces from Microsoft. This was released for several Unix platforms (remember this was before Linux had hit the news), and later for Macintosh. The availability of applications using ODBC on Unix was just about zero, though Microsoft did release their Office suite for the Mac, which used ODBC. Also at this time there were next to no drivers available, so wide acceptance was never going to happen. Shortly after this, another software company Intersolv acquired Visigenix, ODBC support continued within this company, and the range of drivers increased, though this increase was mainly with windows drivers. It is from this period that the ODBC driver that was shipped with version 5 of InterBase originated, though still only supporting Windows. Next Intersolv was acquired by another software company, Merant, who increased the number of available drivers, this time also covering non-windows, but still with no sign of a Unix InterBase driver. Merant appear to have licenced the code for several Microsoft ODBC drivers, and the ODBC 3 driver manager. While all this was taking place, a programmer working for Emperess, Ke Jin, started work on an ODBC driver manager using none of the licensed source from Microsoft. This was done, mainly for Ke Jin's own needs, and once the code had developed to the necessary level, work on this halted. Ke, then generously donated the code to the Free Software Foundation, which licensed the code under the GNU Public license, the GPL.
I have no intention of getting involved here with the merits or problems of open source licensing, but placing the code under the GPL, effectively prevented its use in commercial development, or at least with commercially available drivers and applications. At this time another company entered the dance. OpenLink's CEO contacted Richard Stallman, of the Free Software Foundation, to request that the license for Ke Jin's code be changed from the GNU public license, to the Lesser GNU public license, or LGPL. This change would allow the use of the code commercially, without requiring any accompanying software, to also be covered by the GPL. This discussion took place for some time in public discussion forums, and at times became, shall we say a little heated.
While all this was going on, a Canadian developer, Peter Harvy, who had been watching this "debate" for some time, decided to start a new open source ODBC project, this was originally named LinuxODBC, but soon became renamed UnixODBC. From the beginning the aim of UnixODBC was to provide exactly the same API and features available to the windows programmer, but to as many non-windows platforms as possible. Ke Jin's code was still based on ODBC 2.0, and as by this time ODBC 3.0 has been in common use for several years, Peter decided that UnixODBC would be based on the newest standard. The first public release appeared on the 28th of January 1999, and was followed over the coming months by a number of releases. Another goal of UnixODBC was to provide the same interface, for the end user of ODBC, not just for the developer. To this end a GUI interface was developed to enable the configuration of drivers and data sources. One of the major pieces that Peter was missing was the driver manager, and as I had been thinking I could create a driver manager for some time, I volunteered, to create the new ODBC 3.0 driver manager. This had its first public appearance, in May 1999. In July of that year, Peter was forced to step down as project lead, due to other commitments; I took over the role, and have continued in that position to this day.
The development of UnixODBC continues, with support now in place, for such features as Unicode drivers and applications, connection pooling, and Gui testing and configuration tools. It has been proved in many situations and has become the Standard for providing ODBC on Linux and Unix, being included as standard by several Linux distributions, notably RedHat, Mandrake, and Debian.
ODBC and InterBase
Ok, now you know about ODBC both on and off of Windows, now let's talk a little about how InterBase fits into all this. InterBase 5.x and before was supplied with the previously mentioned Windows ODBC driver produced by Intersolv. This supported SQL dialect 1, and can still be used with current versions of InterBase. I am not sure exactly how the license stands at the moment with this driver, and if it is strictly legal to continue using the driver, from earlier downloads of InterBase.
The user of InterBase 6, is now somewhat spoilt for choice with ODBC drivers, at the time of writing there are at least 4 in differing states and with differing cost and availability. These are (in no particular order). The Easysoft driver, written by myself, The Gemini driver by Aleksey Karyakin, the IBPheonix driver by Jim Starkey, and the driver that's now part of the Open Source InterBase development, that originated with XTG Systems. Like all software, these drivers have their strengths and weaknesses, and to avoid overtly advertising our driver, the best thing for the user to do, is to try them until one is found that matches the requirements, both in cost and performance.
At the time of writing, there are beta versions of both the Gemini, and Easysoft driver, which offer Unicode support for those applications that can make use of Unicode data. At the moment only the Easysoft driver that is commonly available for non-windows platforms, but porting a driver to unixODBC from windows is a comparatively simple task, so I expect more will follow.
All these drivers work via the Interbase Api lib, GDS32.DLL as mentioned earlier, but it seems that the Gemini version 2 beta driver has incorporated the functionality of that lib within the driver. I did consider something similar with our driver, as it would offer the possibility of a performance improvement, but decided the possible future problems with changes to the InterBase native protocol, would make it less attractive, time will tell on this.
There are a few other differences between the drivers that are worth discussing, again I will try and do this without bias to one particular driver. All the drivers with the exception of the Easysoft one, started life as an ODBC 2 driver, and have had ODBC 3 functionality added, as it became required. The IBPheonix driver seems to be a hybrid of two and three. There are no big advantages to the user for either version; I chose three, as I have found that a pure "three" driver is in many ways simpler to write, as the driver manager will enable older ODBC 2 applications to work with it without any change, and newer ODBC 3 aware applications like ADO (which we will talk about later) can make full use of the newer features introduced into ODBC 3, for examples descriptor handles, and records. All but the Gemini beta driver, offer, only forward only result sets, this may be seen as restrictive, but without support for scrollable cursors in the underlying database, there are few ways of efficiently implementing these, without reproducing functionality that is either available in the cursor library supplied by the driver manager, or through the application detecting at run time, what cursor support is available and adjusting its mode of operation to match.
As InterBase implements a strong subset of SQL92, the ODBC driver is not required to provide much in the way of preprocessing of the incoming SQL text. There are a few areas, especially when stored procedures are involved, where some magic is required behind the scenes, but generally the ODBC Api maps very nicely onto the native, InterBase Api, greatly simplifying the drivers task, and enabling good performance as a result.
As we will see later, many of the other data access methods open to the InterBase user offer both native access via the GDS interface library, or equivalent functionality via ODBC. With the general availability of ODBC solutions, I feel ODBC can offer many benefits, even when native access is available, but then considering my involvement with ODBC, it may not come as a surprise, that I hold that opinion.
It would be easy to produce a huge list of applications that work via ODBC and allow connections to InterBase, most windows users will have their own list of "favorite" applications. All the standard ODBC using applications appear to work correctly when using any of the released InterBase ODBC drivers, there still seems to be work to do using the Open Source driver, and I am unaware of the current state of the IBPheonix driver. There is an increasing number of non-windows applications that now employ ODBC to access data. Of these I have successfully used InterBase drivers with StarOffice (now from Sun Microsystems), and Applix Office from Vista Source. There are an increasing number of applications and utilities that use ODBC on non-windows platforms, spurred I suspect by the inclusion of ODBC on Linux distributions like Red Hat.
ADO and OLE/DB
ADO (ActiveX Data Objects) is an interface method, originally developed by Microsoft for use in their development tools, first Visual Basic, and later Visual Studio. It is also available as part of the generic Visual Basic for Applications, which is made available to users of many Microsoft products, such as Access, and Excel. It is also available, as we will see later, to web designers via Active Server Pages (ASP). Both methods provide a loosely object oriented interface to the underlying database, with methods for all the normal database operations, opening connections, creating and updating record sets and so forth. ADO replaces and builds on, the older Data Access Objects (DAO) and Remote Data Objects (RDO) interface methods. ADO makes use of the concept of data "Providers", Microsoft has OLE/DB providers for their own databases, and there are third party providers available for most commercial databases. Microsoft also supplies an OLE/DB to ODBC Bridge to enable any conformant ODBC driver to be used with this technology. As we have already covered ODBC in depth, I will restrain myself from discussing this beyond saying that this works with most of the existing InterBase ODBC drivers.
Underlying all the current Microsoft data access methods, is OLE/DB, which is now considered by Microsoft to be their standard low level data access method, replacing ODBC. OLE/DB was designed to enable the use of both relational and non-relational data stores, but as we are discussing InterBase, it is only the relational aspect that concerns us here. There are several projects currently underway to provide a native OLE/DB provider for InterBase, including a driver from Jason Warton of IBObjects fame, and one from a Brazilian developer from Soft Software this is the SIBProvider. I have used the later driver, and it seems to work well, though there is a potential problem with result set's containing large numbers of rows, as it seems that the results are stored locally, presumably to enable scrolling.
Perl has been described in the past as many things, the programmers Swiss army knife is a good positive description of it, as is the less complementary description of a "write only language", this being a comment in the ease of which powerful programs, may be created, that within seconds of writing are incomprehensible to any programmer, including its writer. There is some truth in this, but as someone once told me "You can write Fortran in any language". Simply put Perl is a scripting language, which to quote was, "originally written by Larry Wall, and a cast of Thousands". It is based in part on C syntax but adds many features from tools originally used on Unix systems, such as awk and grep. Perl is built around the concept of "regular expressions", and these provide enormous power and flexibility, though this has resulted in its reputation as creating unreadable code. While it is a scripting language, and there is no concept of a Perl compiler, the Perl runtime converts the source files into a byte code representation, providing error checking, and then executes the generated byte code, often at remarkable speed. The concept of really portable code, and byte code operation, seems to have been introduced by the developers of Perl, in advance of the similar features employed by other languages such as Java.
Perl is available both for Windows and Unix/Linux systems, and consists of a core language to which the user can include a huge range of modules; there are modules available for just about anything you can do on a computer. Perl for Unix is available both as source, and precompiled binaries. As the modules may be added later, extending support for InterBase on an existing installation is normally a simple matter of adding the required module. Perl support under Windows, is, as is often the case, not quite as simple, but a company ActiveState, now owned by Microsoft, have ported Perl to that platform and provide support and binary distributions for many of the modules, including those discussed here. There is an archive for Perl modules available on the Internet, called, "The Comprehensive Perl Archive" or CPAN for short, and this provides many resources to both the fledgling and experienced Perl coder.
The Modules that concern us here are named DBD::Interbase and DBD::ODBC, there is a double colon in both these names, which is a reference to the object oriented nature of current Perl. The DBD part of the name refers to a "Data Base Driver", this works in conjunction with the Perl "Data Base Interface", or DBI for short. Before looking at the specific features when used with InterBase, we shall first look at how database support is implemented within the Perl environment.
The standard database access method for Perl is called DBI, to quote Tim Bunce, the original author and architect, of DBI (and author of the reference book). "DBI is a database access Application Programming Interface for the Perl language. The DBI API Specification defines a set of functions, variables, and conventions that provide a consistent database interface independent of the actual database being used". The programmer writing Perl scripts that access DBI, uses a set of object that provide a abstracted view of underlying database activities. The actual implementation of DBI relies on one or more DBD, or Data Base Driver modules, to provide the actual interface to the database in question, and like ODBC these are loaded at runtime, so the coder can interface between one or more DBI drivers using the same Perl script. Installation of DBI, is a simple matter, and will be familiar, to anyone who has installed a Perl module in the past. There are many on-line references to help the first time user, and again I can recommend Tim's book. Installing the DBI InterBase driver is equally simple, requiring little more than the standard Perl install mantra, "perl Makefile.pl, make, make test, make install", and that all there is to it. Installing DBD::ODBC is slightly more complex, in that it is necessary to have a working ODBC subsystem in place before repeating the standard install steps. I would suggest making sure that ODBC is installed and working before setting up DBD::ODBC.
It is also worth noting, that for these situations where a direct programming interface to the InterBase API is required, there is a Perl::Interbase module. This provides Perl wrappers around the basic GDS API, and may be useful where InterBase specific features are required, for instance, creation of databases, or access to ARRAY column data, which is not available using other methods.
If there are problems, a host of on-line references are available, and several newsgroups and mailing lists, where you will find generally helpful people, however I would suggest reading the frequently asked questions, and README files, before asking online.
PHP, like ADO, is a server side scripting language for use in web servers, unlike Ado it is an open source project, and the source is freely available on the Internet. It is included in many Linux distributions but can be simply added to existing setups. It is often used with Apache, on Unix platforms, but is not restricted to just this environment. It can be used with several web servers, including the aforementioned Apache, Microsoft IIS, Zeus, Netscape Web Server, AOL server and the Roxen web server. It runs on most Unix variants, Linux, Windows, and many other platforms. It may be built either as a part of the web server software, a dynamically linked module loaded at run time, or a standalone binary, that can be used via the common gateway interface.
The name PHP currently stands for personal hypertext processor, though it appears to have had different meanings in the past, and may again change. PHP is currently used on web servers supplying over six million different domain names, and nearly one million different IP addresses, publicly accessible on the Internet, not to mention a unknown number of private Intranet sites.
To install PHP, it is normally a case of building from source, this process will be familiar to most Unix and Linux users, but may be a source of problem for windows users. Precompiled binaries are available, but because of the modular nature of PHP, it may be necessary to search for a binary with support for ODBC or InterBase.
When building PHP from source, it's a matter of selecting the required modules, there are modules to cover just about any possible web site requirement, and at the time of writing there were a total of 83 different modules provided with the standard distribution. Only the required modules need including, so the final binary size need not include unwanted options, reducing memory usage, and disk space requirements.
The modules of interest to us here are the InterBase, and unified ODBC module. Unfortunately, due to conflicts between the headers it is difficult, though not impossible to enable both these options at the same time.
Whatever your needs for data access and web design, its worth giving PHP a look, like most open source projects it's a continually developing product, with a good informative web site, a lot of good informative books are now available, and there is an enthusiastic group of developers and users, willing to offer help and support.
Microsoft's Active Server Pages provides a method of server side scripting for web developers using Microsoft IIS web server. The scripting language is based on Visual Basic for Applications, and the data access method is ADO as discussed before. As ADO is used, both ODBC and OLE/DB drivers may be used, and good performance can be obtained though the combination of ODBC and the support for connection pooling supplied by the Microsoft driver manager. This pooling reduces the time taken to serve a page of data, by retaining open connections to the database in a "pool", and reusing them when required. I personally have some concerns about using OLE/DB drivers for InterBase in this situation, as the possibility of returning large numbers of rows, and the potential memory implications of this, on a web server, may provide an avenue for a form of a denial of service attack, because the existing ODBC drivers do not attempt to provide client side caching of result sets, they are not vulnerable to this. I am not however of any actual cases of this occurring. The creation of active server pages should be familiar to programmers used to Visual Basic ADO coding.
Support for Active Server Pages, is no longer limited to IIS running on Microsoft Platforms. A product called Chili!Soft ASP, from a company of the same name, which have since been acquired by Sun Microsystems, provides run time support for Active Server Pages on several Unix platforms. The current release of this product for Linux contains a ODBC driver for InterBase, which I believe is the IBPheonix driver. In my experience this product works remarkably well. I have used it myself to test the Easysoft ODBC driver (replacing the supplied one), as I find it much easier to debug drivers when using Apache.
This does bring us to a point worth repeating when using any InterBase connection method in conjunction with Microsoft's IIS. As mentioned at the beginning, when a process connects to a local InterBase database, it runs as part of the calling process, if this process is IIS, then the process has very restricted access to resources on the server, this is done for security purposes. If the location of the database file is outside IIS's web root, or not in a location specifically marked as accessible, attempts to connect to the database will fail. The solution to this problem is simple, just specify a client-server connection to the database, this will cause the access to the database file, to be performed by a separate process, this will not have the restricted access of the IIS process.
Other Web methods
It would be unfair to the companies and individuals behind them, to not mention two other products, which enable the creation of web sites, interchanging data with Interbase. These are iHTML from Inline systems, and ColdFusion by Alaire, though Alaire now seems to have been acquired by Macromedia. Both products enable the creation of data aware web sites, both can connect to InterBase through ODBC, and both are available for web servers running on Windows, Linux and other Unix platforms. Each product has its own syntax for writing pages, and each has its own enthusiastic group of users.
JDBC or Java Database Connectivity is the standard data access method for software written in Java. It is based on ODBC, and is implemented as a set of classes and methods providing all the expected database operations. JDBC drivers come in four types, named not surprisingly type one to type four. The type indicates two things, if the connection to the database uses the native interface protocol for the database, and if the driver is written in pure Java, or includes a interface to a non Java layer. As an example a type one driver, provides a JDBC interface to a local database, using a non-Java component. The presence of the non-Java component means that the driver is not portable to other platforms if the non-Java part is not portable. At the other end, a type four driver makes a client server connection to a remote database using all Java on the client, and the native communication protocol to the remote database. The use of the native communication protocol means that there is no requirement for the installation of a separate server component on the database server. At the moment there is only the one type three driver available for InterBase, this is the InterClient/InterServer combination. The InterClient component provides a pure Java JDBC driver, using native JAVA network methods to connect to a non-Java server component InterServer. This server component uses the standard GDS interface library to communicate with the InterBase server. Other methods are available to connect via JDBC to InterBase, including JDBC-ODBC bridges from Sun and Easysoft. It would be possible, to create a type 4 JDBC driver for InterBase, it would require as a first step, the reverse engineering of the client-server network protocol provided by GDS, but implemented solely in Java using standard Java networking support.
There is another issue when considering development using JDBC. Java programs may be run in two methods, first as a stand-alone application. In this mode the executing program can perform any network operation it needs, connecting and disconnecting as required to any remote network server. The other mode of operation is as what is known as a "Applet", this is when the Java application is downloaded from a web server, and is running within a users browser. In this mode for security reasons, the applet may only make network connections to the server that "served" the java applet. This means that the InterServer process must be running on the same machine as the web server.
Java and JDBC suffer from a multitude of version, but the major JDBC versions are one and two. At the moment InterClient provides a JDBC 1 interface, several of the JDBC-ODBC bridges provide at least part of the JDBC 2 interface, but as JDBC 2 requires scrollable cursors, it will not be a task simple to provide a complete version two driver.
It is also worth mentioning, JSP, or JavaServer Pages, these enable the creation of server side scripting using JAVA, and of course these scripts can make use of JDBC, and so InterBase. JSP, can be considered as the JAVA version of Microsoft's ActiveX server Pages, or PHP scripts, in that they enable the dynamic creation of web content, and unlike Java Applets which run at the client end, the JSP run on the server.
We have seen that the options available to the developer whishing to create applications using the power and convenience of InterBase, are many. The nature of the software world means that through the continual process of innovation, the number of methods available will only continue to increase. The wide acceptance of InterBase and its very openness ensures that it will keep pace with future developments, with new people joining the community of developers committed to enhancing and embracing its support in the future, we can look forward to it being with us for some time to come.
Having presented all these options for connectivity, the one thing I cannot, and should not do, is attempt to convince the developer that one method is in any way superior to another, its not, and part of what keeps us (as developers) creative and enthusiastic about what we do, is the very range of choices available. Personal choice as to language, requirements for support and interoperability all will enable the most appropriate choices to be made.
Through the on-line community that exists around InterBase, ideas and methods of using this database will continue to evolve and expand, and I for one, am looking forward to where InterBase takes itself, and hopefully all of us in the future.