Since we're in the database engine software business, I'm always interested in what type of software is used in various local businesses that I patronize. More specifically, I'm always interested in seeing what various ISVs are using for their database engine for distributed Windows desktop applications.

Haircut Day

---

Recently, I was due for a haircut so I headed over the hair salon for a cut. In case you're wondering, I've tried barber shops in the past, but frankly, they just don't stack up to a proper hair salon unless you want a "high and tight" (ask a US Marine, if you don't know). At any rate, after I was finished and was settling up at the counter, I asked the owner the name of the software she was using to manage the salon. She was happy to share lots of information with me and, armed with that information, I headed home to do some research on this particular software. It was particularly interesting to me because the software took quite a while to load (> 45 seconds) when she was showing it to me. She blamed this on the computer being old, but I knew that her computer would have to be something from around 2000 or earlier to be that slow, and that certainly was not the case.

Exploring...

---

Once I got home, I quickly Googled the name of the software, found a trial version, and started downloading the setup executable. The first thing that I noticed was the size of the download, which was a whopping 86MB. Granted, this isn't a showstopper issue, but it made me start to wonder exactly what was in the setup executable. Once the download completed, I started up the install directly from the setup executable. The executable was digitally-signed: so far, so good. Part-way through the installation, the installation stopped with a prompt indicating that it was going to start installing SQL Server 2005 Express. Ahhh, there's around 36MB of the installation size right there (the rest were .NET assemblies, but that's a different blog post ). I clicked the OK button to continue on with the installation of SQL Server 2005 Express, and halfway through the process the installation failed. Uh-oh....

The Ship is Sinking...

---

The issue with the installation was that I already had an installation of SQL Server Express on my machine, and the installation process for SQL Server 2005 Express refused to continue installing into the same target directory. Unfortunately, there were no options to install into another directory, or do anything else to fix the problem. If I were an actual potential customer, I would probably give up at this point, uninstall the software, and move along to the next software package to evaluate. If the vendor of the software were lucky, I would call them for support, and they would have to walk an end user through the very confusing process of getting a SQL Server Express installation straightened out in a way that would allow the software package to use it. And all of that time would be money being spent on something that should never happen in the first place.

The Moral of the Story

---

The problem with using scaled-down database server engines as database engines for highly-distributed applications is two-fold:

• In many cases, such database engines are not customizable, especially with respect to their installation. Furthermore, they often expect to be the one-and-only installation on a given machine. This is not a realistic expectation for highly-distributed applications and, as an ISV, it would be a big mistake to assume that your application will be the only application trying to install a particular database engine on a particular machine. This is especially true if the database engine is used by many other ISVs. You may be able to structure an installation so that it can work around such conflicts, but there may be service name conflicts and other potential problems that will ultimately cause issues.



• Even if you do manage to get a clean installation on a particular machine, there is no way to prevent a different application from installing its own database engine instance and, in the process, disabling or breaking your application. And guess who they're going to call when your application stops working properly ?

Both of our products, ElevateDB and DBISAM, allow you to compile the database engine directly into your application with Delphi 5 and C++Builder 5 and higher. When using other environments like older versions of Visual Studio, both products offer an ODBC driver that consists of the entire engine as a single .DLL that can be locally installed under your application directory. Finally, for Visual Studio 2005 and higher, ElevateDB also offers a specific .NET managed code assembly that can also be locally installed under your C#, VB.NET or Delphi Prism application directory. Both products are around 2MB in size, and do not require any external DLLs or large, complicated installations. Simply copy them to the application directory and go.

Our products have been built from the ground up with one thing in mind: making distribution and installation as simple, easy, and support-free as possible. Don't let your database engine interfere with your ability to get your customers, and potential customers, into your application as quickly as possible. The faster that they can download and install your application, the faster they can start enjoying the benefits that you have worked hard to provide for them. Meanwhile, you can keep your profits and stop spending so much on unnecessary support costs.

---

Tags: ElevateDB, DBISAM, Distribution, Support Costs

Permanent Link

Comments (3)	You must be logged in to comment
Daniel Kram said...	Reply
I am of course not sure of what point-of-sale, or POS, software you downloaded, however, I have downloaded a POS package and it behaved exactly as yours. In my case, I dug around the forum for the software and found I could download the demo DB and tweak a setting to "complete" the installation, however, as non-tech potential Customer, I would not have gone to such lengths. The embedded aspects of ElevateDB is one of the primary reasons we chose this product. Is MySQL or SQL Server more robust or more powerful: debatable, but are they bigger - absolutely. Summary: Developers - strongly suggest to Management to have the software tested in as many situations as possible even if it delays delivery a little. Delayed delivery is better than losing Customers.
Tim Young [Elevate Software] said...	Reply
I can't say the name, for obvious reasons, but it was a nice package apart from the bulk and the installation issue.  The hard part to understand is the logic behind using a database engine that is so overly bulky for something like a hair salon.  I think it's just a case of the company trying to make things easier on the development side (SQL Server is the default database for everything in Visual Studio), and ending up making things harder for the customer (and the support staff).
David Cornelius said...	Reply
This very thing (trying to get SQL Server Express to work) is what moved me to build an application with ElevateDB. When starting development on the application that my customer has now been using for a few years, I hadn't yet decided on the underlying database but had been reading a lot about SQL Server Express.  I bought a book about SSE and read many articles about how to configure and install and setup instances using their monolithic engine.  Not only did I have SSE already installed, but I had another application installed that had added a database instance for its own use.  How hard could it be for my application to add one?  Well, it turned out to be a nightmare that I could never quite figure out (too many different potential scenarios to account for).  I knew there had to be a better way. I had used DBISAM in a previous application and decided to check out ElevateDB for the new one.  It turned out to be a very good solution and I have been extremely happy with the small footprint and ease of development and deployment with Elevate Software products.  (The support is terrific, too!)