The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

moving from a single-user system to multi-user system

I have a desktop app with all the data stored in an XML document file. This works fine for a single user.

I have had a number of requests for a multi-user (client-server) version of this app. The access to the data is all handled by a single document class so, in theory, I could just re-write that to talk to a database instead of an XML file, but adding in concurrency 'after the fact' sounds like a total nightmare.

Has anyone tried to transform a desktop app to a client-server app? How did it go?

Are there any 'light-weight' multi-user databases that integrate well with C++ on Windows and are easy to install and maintain? The databases are quite small (typically less than a thousand objects) and writes aren't very frequent, so performance isn't a huge issue. The system will probably sell for around $1k, so I can't pay big royalties.

I worked with object databases years ago. Are any of them still viable?

Is it practical to just use document level locking around an XML file? i.e. prevent anyone else writing to the XML file while you are writing to it (using Windows file locking?), and have everyone else polling periodically for changes. No server required.
DeadlyEmbrace
Thursday, September 20, 2007
 
 
Lyn Thomas Send private email
Thursday, September 20, 2007
 
 
From:
http://www.hwaci.com/sw/sqlite/whentouse.html

"If file locking does not work like it should, it might be possible for two or more client programs to modify the same part of the same database at the same time, resulting in database corruption. Because this problem results from bugs in the underlying filesystem implementation, there is nothing SQLite can do to prevent it.

A good rule of thumb is that you should avoid using SQLite in situations where the same database will be accessed simultaneously from many computers over a network filesystem."

That doesn't sound terribly confidence inspiring. Database corruption is just about the worst possible bug (next to setting their PC on fire).
DeadlyEmbrace
Friday, September 21, 2007
 
 
You might want to take a look at Firebird.  I use it with C++.  It is a fast, compact client/server SQL RDBMS.  It is very stable with almost no administration required which is what my clients need.
DaveW
Friday, September 21, 2007
 
 
Does Firebird need a server component - if so, is it easy to install? I locking file or record level?

Had a quick look at the firebird documentation, but couldn't see the answers to the above.
DeadlyEmbrace
Friday, September 21, 2007
 
 
3-5 years ago my main environment was Borland C++ Builder with MySQL databases, I cannot complain of any problems.
I still code in Delphi
Friday, September 21, 2007
 
 
Yes Firebird has a server component.  It is primarily client/server.  However, Firebird also has an embeded version.  But, even for single user applications I have always used the server component and simply installed it on the local workstation.  Then, if I ever want to convert to a multiuser environment the task is trivial.

The server component is very easy to install, especially on a Windows machine.  A Windows installer is available for download.

Firebird uses transaction-based table locking with lock states ranging from 'free' (any other user can do anything) to 'exclusive'.

If you decide to use Firebird, I would recommend Helen Borrie's book "The Firebird Book" from Apress.  It is based on version 1.5 but is still very uesful.
DaveW
Friday, September 21, 2007
 
 
Off the wall suggestion.  See if your clients would use a source control system like Subversion.  Yeah, it's hackish.
Robbert de Groot (aka Zekaric) Send private email
Friday, September 21, 2007
 
 
re SLite:  you indicated that writes are infrequent.  I took that to mean you could either ignore the possibility of simultaneous writers, or serialize writes yourself.

I used InterBase (the predecessor to FireBird) for a commercial product.  It's a good product, but it gets so little love/support/notice that IMHO it's dead.

If you're willing to pay on a per-server basis, what about http://www.vistadb.net/ ?
Lyn Thomas Send private email
Friday, September 21, 2007
 
 
+1 Firebird Database

I've used the embedded version of Firebird for my time tracking application. And as it has been mentioned it is trivial to make the application connect to a database that resides on the network.

I've recently revised my application to be able to connect to a local database (same machine as the app) or to a network database simply by means of setting an option.
Phillip Flores Send private email
Friday, September 21, 2007
 
 
There's always Sql Server express. It's a full bore MS Sql Server, installation is pretty easy, and it's free.

As long as you don't hit the db size limits (which is in the GB range) you should be fine.
Chris Tavares Send private email
Friday, September 21, 2007
 
 
I've got MS Sql Server Express running on my local machine for a bug tracking app. It seems dog slow for such a small data set. But maybe thats the app, rather than the database.
DeadlyEmbrace
Saturday, September 22, 2007
 
 
Assuming your database isn't going to grow radically in size and complexity you might be able to write your own server rather than search for a RDBMS with alot of feature you don't need.
Let the clients send 'read' and 'write' messages to the server. The server has two threads. One thread receives the requests on a socket and pushes them into a FILO queue. Another thread sequentially pops requests  off the queue and processes them ensuring only one source touches your xml file. For good measure write a backup and a log on each 'write'.
It requires some effort but you own everything. One issue, you need to keep that server alive.
Todd Spurling Send private email
Saturday, September 22, 2007
 
 
Hmm, if you're already going Client-Server, and are doing XML, why not have the server do a simple XML-RPC store/retrieve/update API?  Just have a single thread for the server, and have it work atomically on the file.
Lally Singh Send private email
Saturday, September 22, 2007
 
 
"I've got MS Sql Server Express running on my local machine for a bug tracking app. It seems dog slow for such a small data set. But maybe thats the app, rather than the database."

You're probably talking about the time it takes for the Management Studio to load, and for each different form in the MS to load the first time.  Yes, that's just MS - not the SQL Server database engine.
Karl Perry Send private email
Sunday, September 23, 2007
 
 
I'm talking about how long it takes for this software (OnTime) to do anything. Its not unuseable, just sluggish. There are only a few hundred issues in the database.
DeadlyEmbrace
Monday, September 24, 2007
 
 
Oh no, another XML victim. You see, developers everywhere dying everyday of XML abuse.

But it's not too late. Please migrate to a decent database server immediately, be it Firebird, SQLite, etc. You can enjoy your life without XML as a database server.

Just do not ever do XML databases again.
Ex XML-database user
Monday, September 24, 2007
 
 
Actually XML works just fine as the storage format for a single user app without too much data. Just read it straight into memory and its very easy for other people to integrate with. Obviously I wouldn't have picked XML if I had though I was going to have to move to multi-user. Hindsight is 20/20.
DeadlyEmbrace
Monday, September 24, 2007
 
 
"I'm talking about how long it takes for this software (OnTime) to do anything. Its not unuseable, just sluggish. There are only a few hundred issues in the database."

Axosoft OnTime?

It's slow/sluggish software.  That's not an SQL Server Express 2005 problem.  I've tested Version Control systems that use SQL Server (Express) as their backend and they weren't slow at all...

DB2 Express is another option to consider.  Unlike the other Express versions of commercial databases, it has no database size limits.  They only limit Enterprise features (things any small-scale user probably wouldn't use or think of using).
Nate Send private email
Monday, October 01, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz