Recently, I've bumped into a strange problem. I'm coding some database-ish stuff for the guys at work, which is going rather well. Application is soon ready for test phase. We have a couple of programs here that are run from a "server" - actually just a crappy win98 box with file sharing. Works fine for one database app, and okay for the calendar (though the calendar has been acting a bit odd lately).

Now, the problem. When I run my recent program locally, everything is fine. Works great on win98se and win2k pro. When I stuff the executable and database on the "server", however, SQLite fails. It opens the database fine, but SQL calls hang for a few seconds, then error out with "the database is locked". Tracing into SQLite, the problem happens when the pager code calls the os-lockfile stuff. LockFile fails, GetLastError returns 50, which should be "The network request is not supported." this seems weird however, file locking *should* definitely be shared.

Now the interesting part. The error happens when I try to run the database app from my win2k box. If I run it from another win98 box, it works fine. And of course also locally from the "server". If I put the database app on a linux server running samba, both the win9x clients and my win2k box can run the app without problems.

So... is this a wellknown problem? a bug in 9x or 2k? A configuration problem on the "server"? SQLite doing something funny? I guess I'll have to write a couple test applications doing some simple file locking. Argh.

I'm probably going to ditch win98 on the "server" in favor of slackware9 of freebsd5 soonish, since I want something that can run 24/7 and recovers gracefully from crashes; 9x sucks, fat32 certainlyu isn't journalling, and I don't really want to get a NT4 or Win2k license with the limited budget we have. But it would still be nice to know if anybody has experienced something like this - if it's a problem on my (or SQLite's) end, I definitely want it fixed.

:stupid:
Posted on 2003-03-27 09:22:26 by f0dder
sqlite is not a server database, it doesn't handle concurrent access well/at all

if you need to access a database with multiple clients then you need a good server database :/
Posted on 2003-03-27 09:26:52 by Hiroshimator
hiro, there will only be one process accessing the database at a time, it only needs to be on the "server" so it can be accessed from any of the client machines. It _might_ be used by multiple clients on a few seldom occasions, but only one ever at a time will be issuing writes. My problems are most definitely not related to multiple clients, as I'm the only one aware that the program is on the server at the moment.
Posted on 2003-03-27 09:32:54 by f0dder
depends. If accessing over the network handles file locks differently ... :/


for anything over the network I would use a 'bigger' database really.

sqlite was always single user, concurrent access was added just now, is not guaranteed working and is more of an afterthought.
Posted on 2003-03-27 10:27:24 by Hiroshimator
well. windows filesharing uses the SMB protocol; there's multiple versions of this, and I wouldn't be too surprised if win2k has a more recent version. Bit strange if this is causing problems, though. But I guess it's not too often you see a win2k client against a win98se "server" :rolleyes:

concurrency won't be an issue, so you shouldn't think of this as "over the network" in that sense. It's a book database application, and will only be accessed from one box at a time - and problably even only one box. I want to keep it on the "server" box and access it through the lan, however. One of the reasons for this is that the "server" will be doing regular automatic backups of some of the various data files on the box.
Posted on 2003-03-27 10:55:07 by f0dder