El 17/06/2010 9:39, Luca Olivetti escribió: > > "Concurrency > > SQLite allows multiple programs to be connected to the same database > simultaneously. The embedded version of Firebird does not. If you run > Firebird in client/server mode, it allows concurrent access with > fine-grain locking. But in embedded mode, only one program can connect > to the database at a time." > > Bye
If you write a program manages its own data, configurations etc, you can read sequential files, text files etc. But if the data is very complex and there is a lot of data, instead of reinventing the wheel, you can use a embedded DB, like SQLlite or others. That is what embedded RB were designed for, not to share data. SQLite's concurrency is just fancy feature, not a very useful feature. Concurrency in SQLite is pretty simple. Only a process can write simultaneously, and it locks the whole file and has problems with threads: Check http://www.sqlite.org/faq.html (5) (6). If you want a program (a workstation) that manages data, and the rest of programs read data, SQLite concurrency may be good for you. But even in this case, one process is updating and several processes are reading, you can run into problems: http://old.nabble.com/Memory-Usage-td23154686.html. But if you plan to deploy several programs sharing the same data as peers, updating and reading, SQLite is not the solution, you must use a real RDBMS. You shouldn't rely on operating system file locking systems and clients doing the right thing. You need a single process that controls the file and schedules users' petitions, that is, a RDBMS. But if you think that data will be seldom updated, SQLite may do job. Just be aware that SQLite is not scalable for concurrency. Use the right tool, for the right task. Santiago A. -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
