Pessoal bom dia.
Não sei se alguem aqui ja passou por esse problema que vou relatar. Utilizo o SC e um banco Sqlite. Em produção vez por outra o banco fica inacessivel e creio que é algo que o SC faz. O banco fica com 0 bytes. So resolve com backup que volto, alguem esta passando por isso?
att
Kielber
Quando você diz sqlite é a aplicação ou a ferramenta que usa o sqlite, sobre a ferramenta utiliza, nunca tive problemas, quanto a aplicação/projeto usar, não posso lhe responder pois não trabalho com este banco para produção, somente em uso de testes.
Se for a ferramenta, sugiro verificar sua estrutura onde está rodando os serviços, aparentemente não tem haver com o SC nem o sqlite, mas algo que esteja interferido, se for windows sugiro verificar ainda mais… firewall, antivírus, dentre outros.
Eu tenho vários clientes em produção que tem base SQLite mais é em Windows na Intranet rede local, roda a anos e nunca corrompeu de vez em quando eu passo ‘VACUUM’ via linha de comando .BAT do CMD.
No máximo para 10 usuários simultâneos leitura/gravação.
Se tiver mais usuários que requerem gravação ao mesmo tempo seria melhor mudar para MySQL/MariaDB.
Pode ser algo nesse sentido entao, eu tenho mais de 200 usuarios acessando. ja simultanos deve bater uns 30 a 50
Se fosse só leitura daria para usar, mas como esta gravando também ao mesmo tempo nas
tabelas, ai pelo número de usuários pode estar corrompendo, nesse caso já seria interessante
migrar para uma base cliente/servidor MySQL/MariaDB.
Ta joia, obrigado! vou tentar viabilizar
Multiple processes can have the same database open at the same time. Multiple processes can be doing a SELECT at the same time. But only one process can be making changes to the database at any moment in time, however.
SQLite uses reader/writer locks to control access to the database. (Under Win95/98/ME which lacks support for reader/writer locks, a probabilistic simulation is used instead.) But use caution: this locking mechanism might not work correctly if the database file is kept on an NFS filesystem. This is because fcntl() file locking is broken on many NFS implementations. You should avoid putting SQLite database files on NFS if multiple processes might try to access the file at the same time. On Windows, Microsoft’s documentation says that locking may not work under FAT filesystems if you are not running the Share.exe daemon. People who have a lot of experience with Windows tell me that file locking of network files is very buggy and is not dependable. If what they say is true, sharing an SQLite database between two or more Windows machines might cause unexpected problems.
We are aware of no other embedded SQL database engine that supports as much concurrency as SQLite. SQLite allows multiple processes to have the database file open at once, and for multiple processes to read the database at once. When any process wants to write, it must lock the entire database file for the duration of its update. But that normally only takes a few milliseconds. Other processes just wait on the writer to finish then continue about their business. Other embedded SQL database engines typically only allow a single process to connect to the database at once.
However, client/server database engines (such as PostgreSQL, MySQL, or Oracle) usually support a higher level of concurrency and allow multiple processes to be writing to the same database at the same time. This is possible in a client/server database because there is always a single well-controlled server process available to coordinate access. If your application has a need for a lot of concurrency, then you should consider using a client/server database. But experience suggests that most applications need much less concurrency than their designers imagine.
When SQLite tries to access a file that is locked by another process, the default behavior is to return SQLITE_BUSY. You can adjust this behavior from C code using the sqlite3_busy_handler() or sqlite3_busy_timeout() API functions.