MS Access 'equiv' for Linux 3297

Michael Heiming machine embedded same

The problem, in my experience, with networked file-share dbs, is that because the engine does't "really" offer concurent read-write access from multiple clients, that precisely lack of knowledge of "normalization" and "update anomolies" is the source of problems with db corruption-inconsistencies.

You (as a db-app designer) can get around it (and increase network throughput) by submiting queries to a "query table" on the "server", which serializes query (update) processing by polling the query table and returning results to temp tables for each client (in effect, clients are always accessing db views), but it does require quite a bit of boiler plate on both the client end and the server end. At which point, why not just use a db designed for that purpose? $$$ Though GPL and OSS has greatly impacted that revenue stream;)

OOo 2.0 raised a stink (but I have a tolerant nose regarding most religous issues;) because of the Java requirement for the new db backend, dbf is just not lovey enough anymore(?), and they were quick to "uncommit" themselves that the new db will be the ongoing standard. Not the sort of stuff that db designers-users want to hear, don't you think? I certainly hope they can come together on something that does not require Java for the datastore as OOo is bulky enough without requiring Java to be loaded just for db use. "Why does mail merge bog down my desktop?"

I think the folks at OOo, and Linux db parties in general, really are trying to come up with something that is better in several senses. But it's tough work to do so while not introducing "something completely different." End users need some level of familiarity.

regards, prg