How I came to Interbase and other SW.Because this is one question that I don't want to repeat many times or clutter a list or newsgroup to explain or bore people that want to spent better their time, I will put here my personal experience. Really this must be "how I came to Interbase and all other tools and products", because this is a complete description. Disclaimer: opinions put in this page are the product of my personal experience so they may be radically different from other opinions. I find useless to waste time discussing them. I used to be a mainframe man in the university. In 1989, PC infrastructure was very weak and poor with a few 8088 and two 80286 in the room for general use. The most powerful computer had 512 KB in RAM. Diskettes of 5¼" were 320 KB in capacity if I remember well and they failed very often. In contrast, the IBM machine, then an already old model VM9370, had 16 MB in RAM and it was very reliable, because the bad clusters were assigned by the administrator so one never stumbled with a defective zone in the virtual minidisk. Also, it had a rather archaic Pascal/VS compiler. At the same time, in the first year at the university, I learned to use another primitive Pascal compiler, in an ancient multi user machine known as Alpha Micro (never knew what it was really and if it had some connection to DEC or not). Furthermore, there was a DEC2020, preserved as a legacy machine for some people that still maintained information in its disks. So, the first suspicion I want to clear is I learned Pascal in mainframes or small multi user servers and not directly on the Borland's product, so I had a chance to compare and elect. Apart from the Pascal/VS, assembler and Fortran compilers, the VM9370 had some interpreted languages, the most notable of them being REXX. I spent two years in that language that still survives in the form of NetREXX, as an alternative for Java. One of the most intriguing interfaces was some ISQL facility that was installed in the IBM machine. Although I used it sparingly and only for curiosity (I still didn't have any class in relational theory, so I didn't understand really what I was using), I deemed interesting the idea of getting results using "filters" and without taking care of the details in the retrieval process: I never worried about the internal ISAM or VSAM structures to hold the little amount of test data I filled in. So, I used SQL in 1990 without realizing that this might be my future. However, as the IBM machine was aging quickly, I decided to go to UNIX realms. Here I enjoyed programming in C over the SunOS's API and sockets. I programmed at the CRT level, no graphics at all. But as HW resources were scarce I decided to give PCs a try. At that moment, the diskettes had been enhanced and they were 3½" and 512 KB with promise for 1.44 MB in the short term... and they lasted more than previous designs before to die. I began exploring DOS 3.3 and soon 4.X and I started using Turbo Pascal, perhaps version 3. There were other Pascal compilers available, but TP was fast and small. I remember some stripped old version being able to run from a diskette. So, the second suspicion is that I was not forced into Turbo Pascal, although it was the de facto compiler for students due to its small footprint and fast compilation. Other offering couldn't match it. Even MickeySoft had a Pascal version that nobody remembers. Next year I had to return to UNIX and fought against Sybase, its ugly tools, poor performance and cryptic documentation. Without need to say, I didn't like it, although it was the first real relational server I worked with. Ingres or Informix was installed, too, but I never used it. I had the opportunity to use some Sun workstations and the display was really crisp and clear. I enjoyed Emacs (it remembered me the XEDIT editor in IBM's 370 machines, but UNIX gurus never liked that comparison, of course) and several email and newsgroup utilities while I was programming in C++ with gcc. I thought that I was better at the system level, console level but not in the graphical arena. In the same days, I got Borland C++ 2.0 so I had a chance to test the same programs on both UNIX and DOS. In DOS, too, I learned to write Clipper programs so I knew the Xbase format, although I almost never used Dbase through its interface. I had to return to the IBM machine to write some COBOL program and others on the PC platform as part of my classes. These were days of word processors contained on one diskette. Wordstar was my favorite, although I abandoned it when I realized some basic version of WordPerfect was able to fit in one diskette, too. I didn't use Windows at this time. It must have been Win3.0, I believe. Borland C++ 3.0 was here with more power and I almost stopped using Pascal. And I learned like most of you the use of Sidekick and other TSR programs along with several small editors and utilities, tweaking DOS configuration files, etc. When Win3.1 was installed, things bettered but I had a reticence against graphical environments. I needed time to get accustomed to that "manipulate with care or crash" interface proposed by MickeySoft. In 1994, MS-Word was surpassing WordPerfect, MS-Excel was outselling QPro and Lotus123 and MS-Access was taking over Paradox. I learned Paradox in theory and how to call it from C++ by buying a book but I never had a chance to use the environment. Lotus filled a lawsuit against Borland for the menu layout and Borland filled a lawsuit against Symantec for trade secrets. AFAIK, Borland won the former and in the latter there was no real winner. Late 1994 was also the time I was hired formally the first time as a C++ programmer, being still a student in the middle of the engineering career studies, because I already had experience teaching C/C++ to other students. I had to live 200 km away from home for two months and then 100 km away, because I was hired by another company for one month in the main city of our country. Between 1992 and 1995, I watched a team of friends to assemble a large SW product to control and plan the industrial production. The project was developed in the university with Visual Basic and Sybase. I began learning VB but I didn't like it, because it was too fragile, had no decent exception control, no strong data types and no decent database support. Worse, the data was related in a hierarchical way, so the retrieval was a painful process and add to it the inherent slowness of VB. The project succeeded, but the poor performance remained as a black spot. I think that this was aggravated by the design devoid of stored procedures, so the client and the network did the work. Being an strong advocate of both OO languages and OO databases, I knew that one reason CAD programs use their own proprietary storage format is because relational databases are not good at retrieving complex or deep hierarchies and entities with a lot of relationships. I proposed an alternative solution using raw C++ instead of VB/Sybase as a persistence engine, but the task proved to be unfeasible for a teacher plus me in a reasonable timeframe, so I had to let my friends follow their relational route. This great failure didn't destroy my fascination for the OO power and hence, I spent almost 4 years researching OO concepts and implementations until I graduated in early 1998. At the end, I proved with a working application that the idea was feasible but using libraries that were developed across many years by a commercial company, so my real failure was to underestimate by orders of magnitude the amount of work needed to start from scratch. I was wondering if it would be possible to have the benefits of a RAD environments but without throwing to the trashcan the reliability, efficiency and robustness. Clearly, VB was (and is still in VB6) a language with objects but not an OO language. You cannot inherit from standard components, you don't have exceptions, you couldn't compile. Ok, from VB5.0 onwards you can compile, but there's no real gain in performance. I took a peek at Visual C++ 1.0 in January 1994 and it was ten light years of being "visual", so BC++ was still far better in design and power (OWL was gold and platinum when compared to MFC) even though it produced slower executables. And VC didn't improve over VB in the database arena. It was one of my friends working in the VB/Sybase project that brought to me a Computer Shopper article at the beginning of 1995 where a mysterious product from Borland, code-named Delphi, was announced to be released in mid March. There were screenshots of the palette and the object inspector. I was convinced this was my salvation to take the Windows route. I loved the console utilities but clearly my future clients would claim for windowed applications. Also, it was clear more and more products (even being scientific applications like the ones I had experience with) need data storage and using plain files was counterproductive and error prone. CA-Clipper was in evident fall and I never liked it because it was buggy; I preferred COBOL. At that time and not being a trends analyst, I couldn't predict that Windows would take over UNIX only to have Linux in 2000 taking over Windows as a sort of revenge. So, I was one of the first buyers of Delphi in my country. I did my first academic project with Dbase tables and didn't like it, because the format was buggy. I understand Mr. Katz has done a great "cleaning work" since he acquired Dbase from Borland. There were a few machines with CD-ROM readers available back in 1995. For this reason, I was granted an additional copy of Delphi only in 15 diskettes and with them I installed D1 on my teacher's computer. I remember I ended up using her computer much more than her (give us a hand and we will take the arm). When I was able to review the Delphi1 CD, I discovered a directory named INTERBASE. A very brief "read me" talked about Interbase WorkGroup Server (remember D1 was launched before Win95 so the CD-ROM was targeted at Win3.1) and Local Interbase. No great explanations, no marketing campaign. So, the third suspicion I want to clear is that Borland never sold me Interbase and never tried to convince me of using Interbase. I had to discover it for myself. I still have my D1 box at sight. The customer service was too bad that one must pray before trying to purchase a product. Often, purchase orders were lost by the so called Borland reseller. Fortunately, at some time between 1997-1998, Borland gave the representation to a more decent local company. Before the end of 1995 I created my first commercial program using Delphi with Paradox tables. I believe the application is still in use. The only glitch is when the application was reinstalled on Windows95 instead of 3.11, the 16-bit BDE setup overwrote a newer DLL, but Win95 detected the operation and complained, so it could be fixed by hand. At the time Borland C++ 4.5 appeared (1995), I revisited the IBM mainframe the last time to take advantage of the TCP/IP stack installed (or implanted, as you prefer) and write some internetworking programs in REXX, including a very primitive newsreader. I had the change to play a bit with Solaris and the new Sun workstations. At the end of 1995, I participated in an unfortunate project with students from another university to create a small application for the local representative of General Motors. Although the project was finished, there was a great gap in both theoretical and practical knowledge about C/S developments among the team members, so I decided to quit. However, my remembrances are that we used Interbase to develop and test the project but I don't remember which was the production database engine. In early 1996 I participated in another scientific project related to astronomical calculations. It needed to be in Borland C++ 4.5 and with the salary I was able to assemble my first own PC and installed Win3.11. Using my own computer, I wrote the applications with BC++ 4.5 and OWL for Windows. But I stumbled across a printing problem where my color graphic would only print in a B/W printer whereas in a color printer I saw only a fuzzy spot. In my country, the old Borland's support didn't suck... it swallowed! Owning a license, it was impossible to get even an acknowledgment of my support request by fax. Because the full code was tricky, I decided to create a modulo in Delphi to take over these duties and it was very easy and pleasant. Because I needed some columnar reports that were a pain to align in raw printing code, I bought Quick Report 1.0 and recompiled it to be able to use it in a BDE-less way, because data was obtained from plain files. It was the first time Delphi saved my day. Knowing that Windows 3.1 was a weak pseudo operating system, I decided to install NT 3.51 and then if my C++ programs crashed while in development, I didn't need to reboot the computer. I never returned to 16-bit Windows. I naively thought that NT was slow because my computer was a 486 DX4-100, but when I changed it to a Pentium and upgraded to NT 4 and when I changed it to a Pentium MMX 200, I saw the same problem. Now that I have a Pentium III, plenty of RAM, with a SCSI-3 subsystem and I see how the computer is stuck sometimes, I can be 100% sure the more resources you put, the more resources NT seems to need. At the end, NT is like a black hole: the more objects you throw inside it, the more eager is the black hole. After earning money in 1996 by teaching Delphi and C++ (I was a sort of monopoly in both languages, because no other classmate felt confident with C++ and almost nobody knew Delphi), at the beginning of 1997 I was hired again by the same company 200 km away from home, for three months with an very good salary (in terms of my country, of course), to help finishing a complex C++/CORBA development. In this occasion, I had the joy of fighting with Oracle 7.3 and see for myself how the setup was unable to leave an operative product so the installation had to be tweaked by hand, even though it was the NT version of Oracle. Ultimately, SQL/Net was genteel and decided to work so we could construct our stored procedures and triggers and tested the complete solution. Although I never gained confidence with Oracle, I remember a fast engine but with a very rigid SQL parser, almost useless online documentation and a very low level procedure language. At the same time, a friend was asked to install Oracle on a Sun workstation. I don't know if that had something to do with the fact that I suggested that some Oracle extensions could potentially allow a rudimentary OODBMS emulation with custom code on the client side. Given that he wanted to advance his knowledge of administrative tasks, he took the work with joy. What a joy he had! After three weeks, he was able to deliver an installation that was stable enough for other students to work with, but he found several times himself clueless about the next step to attempt or test. In the long-term, when I returned from my work in C++ and because I already had experienced a basic feel of Oracle, I decided to skip it. I had been investigating OO for three years so then I gathered the money to purchase ObjectStore's small cousin, named PSE Pro C++ and gave it a year of dedication until I graduated with the practical and theoretical work in early 1998, as I wrote above. For that project, I had to learn and master to some degree the Visual C++ beast, so I was happy having three C++ alternatives: Borland, Microsoft and gcc. Because I was able to mimic some relational application with these C++ database libraries (PSE Pro), I thought I will be able to get rid of Interbase. I never have appreciated the normalization process because it's unnatural, so the OO model that resembles the old network model, looked promising. At that time, some events happened: first, the new version of PSE Pro was shipped with a royalty per installation although flexible policy and I was in doubt if I could negotiate by email since I do not speak English. Second, the new MSVC 6.0 wasn't able to compile my old code: the MS compiler threw "Internal compiler error" and I couldn't get past this bug (MSVC has a long history of problems with C++ templates). The same message appeared in older versions, but I found a way to overcome it, by rearranging code. This time I couldn't fix it. Third, my persistence engine was a single user one with support for threads so network connections are your problem if you want to try them. Also, making changes to the schema, because is so tied to the program, it's no joke. This is the price you have to pay for having the same model and representation in both the program and the database and for great performance. Fourth, the product was not compatible with BC or BCB, so I couldn't take advantage of RAD to build the user interface. I decided to use PSE Pro only for research and came back to Interbase, because people demanded networked applications. In 1998, I produced some web applications in the artisan's way: generate HTML in FrontPage or other tool and later intersperse the dynamic code by hand; in my case, it was ASP to access IIS and SqlServer in a NT Server box. Since 1998, I've worked more helping friends to build their projects based on Interbase (one for a private company using BDE and other for our custom-house using IBO) than training developers, because people seem to be interested in having a product and not learning how to develop or maintain it with their group of programmers, even though source code was requested and they acquired a Delphi license. I anticipated that I could make my life teaching C++ but this proved to be very wrong in the last years: people want RAD and less complex languages like Delphi. Also, one source of revenues that were scientific programs are not being requested for now. The Internet has established a combination of OO client programs with relational databases as the de facto environment for commercial applications, with some niche markets for OO databases. Therefore, I continue in the relational bandwagon although I don't throw my interest for C++ and non-relational engines.In 1999, I was rather unproductive due to personal problems but I managed to design a schema to replicate information across a national private network, using SqlServer 7.0. Here I found too many rough edges, for example, the setup of a replication case must be started from zero if you want to modify it, because changing some parameters lead to an unusable configuration that only throws errors and does nothing. Other glitch was that the replication must be scheduled to happen several times a hour if possible or you'll see a lot of records that cannot be conciliated, timeouts and other weird messages. Ultimately, as reported from the people that had to deal directly with the problem, the best parameters are obtained after a trial and error process and many guesswork. Maybe this has its roots in the blocking nature of a traditional relational engine, but for me, SqlServer 7 seems immature in the replication facilities and replication robustness. Currently I'm testing a freelance work that's no more than a little commercial product conceived by an unofficial partner and developed by me. It's based on IBO and Interbase, of course. This is my first work that doesn't have any secured purchaser. Call me a lucky man, but I do not have great problems with corruption in Interbase databases and very poor performance has not attacked me in the last months, so I will continue using the engine as well as offering support in some dedicated newsgroups as I can find time to do that. |
This page was last updated on 2000-12-26 01:27:27 |