Posted by Jim Locker (24.209.104.73) on July 06, 2003 at 22:43:20:
In Reply to: I have a question posted by Derek on July 06, 2003 at 22:42:03:
There are a couple of answers to that. Before I begin, let me tell you up front that I don't have complete information on all of this and some of my comments are educated guesses. I'll point out to you which is which.
First, there is the cost. To provide a database with such an application costs money. To the best of my knowledge (someone correct me if I am wrong) you have to purchase a full copy of dBase, or Paradox, or FoxBase, or whatever in order to use them in such an application. This raises the cost considerably. When you add in marketing expenses and the labor costs involved in writing what is, after all, a fairly complicated application you can see that it gets expensive for the developer.
Now, Superbase provides a run time module. The run time module is a full database engine stripped of all user interface. It only works under program control. We can incorporate this run time module into our package for a fraction of the cost of providing the full application. Thus, although we pay a license fee for each sale, we don't pay nearly what we would pay if we were using a database that required us to provide the full package.
I don't know why a lot of the other databases don't provide such a capability, but it seems that the marketplace is moving away from this. Superbase has been around since at least the mid '80s and there has always been a run time module.
Now I should also point this out. dBase or Paradox (or Access, which really isn't very suitable for this application) can be purchased far less expensively than the full development environment for Superbase. So, we bear a larger up front cost to use Superbase, but we can sell the package with a database in it because of the run time module which keeps the per unit cost under control.
The other major reason that other property management packages for small to mid sized businesses don't have a database in them is because some of the developers are amateurs.
I was recently reading through the site of one of our competitors. What I saw amazed me. Presuming the developer is telling the truth, his package is fairly popular. But on his site he advertised a "feature" that in fact was a very substantial limitation. In fact, this "feature" showed very clearly that the developer had no clue about how to organize a database. Furthermore, although he claimed a large number of users, his update history was slow. This suggests to me that updating the package is difficult, which I would certainly expect from the indicated "features."
So there is that out there, too. (No, I will not tell you who I am talking about). I have seen other things with other packages, but nothing else so flagrant.
I will also point out that all of the high end packages - all of them without exception - employ a database backend. Some use SQL server, some use Btrieve, some use others including Oracle.
Why shouldn't smaller property management companies also be able to use that kind of technology?
Superbase really turns out to be a very good choice. It is not as widely known as many of the others, although it has been around longer. We only know about it and use it because our package originated a long time ago on the Amiga, where Superbase was the premier database package.
When Commodore went out of business, and the Amiga therefore became an orphan, we migrated to Windows, mostly following Superbase (which had already moved to Windows) so that we could continue to use our Superbase applications - including the ancestor of the package we now sell as The Property Manager. Otherwise we would have moved to Unix.
Superbase has evolved considerably since the Amiga days and is really a very impressive environment. In the not distant future (a year to 18 months), a Linux version is supposed to be available. When this happens, there will be a Linux version of The Property Manager, which will give us all a migration path away from Microsoft.