none
String conexão com banco de dados SQLite em rede RRS feed

  • Pergunta

  • Bom dia! Criei uma pequena aplicação em que a base de dados foi criada no SQLite, inicialmente para rodar apenas localmente. Mas agora preciso dela rodando em mais 2 outras máquinas, além do servidor. Pensei em deixar uma pasta compartilhada na rede e um atalho nas outras estações apontado para a pasta; a questão é: Como eu faço para a string de conexão apontar para o pc que será o servidor?
    terça-feira, 14 de abril de 2015 13:55

Respostas

  • Sim.. Tudo o que o SQLite tem, o SQL Server tem tambem, inclusive com a mesma sintaxe.

    O SQL Server express também é gratuito e voce pode baixa-lo aqui:

    https://msdn.microsoft.com/pt-br/evalcenter/dn434042.aspx

    A grande vantagem é que o SQL Server possui um servidor que controla as requisiçoes e por isso pode gerenciar vários usuarios simultaneos, a grande desvantagem é que ele precisa ser instalado.

    O que é uma vantagem do SQLite é uma desvantagem no SQL Server express e vice-versa.

    Na sintaxe dos comandos os dois sao praticamente identicos.

    Com relaçao ao compartilhamento, aqui esta o conselho da equipe de desenvolvedores do SQLite:

    http://www.sqlite.org/faq.html#q5

    "

    Can multiple applications or multiple instances of the same application access a single database file at the same time?

    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.

    "


    William John Adam Trindade
    Analyste-programmeur
    ----------------------------------------------------------


    terça-feira, 14 de abril de 2015 15:49
    Moderador

Todas as Respostas

  • Primeiramente o SQLite nao foi feito para trabalhar em rede.. Sugiro voce pensar em migrar para um SQL server express neste caso, pois possui a mesma sintaxe SQL e nao vai te causar muito problema na conversao...

    Caso queira continuar com a idéia de compartilamento, somente tenha certeza que a pasta tenha direito ao compartilmaneto, depois é só usar o caminho: "\\servidor\c$\pastaBd\bd.sqlite". 

    Mais uma vez, SQLite nao foi feito para ser compartilhado e pode causar instabilidade no seu projeto.

    Att


    William John Adam Trindade
    Analyste-programmeur
    ----------------------------------------------------------


    terça-feira, 14 de abril de 2015 14:10
    Moderador
  • Bom dia Willian,

    Obrigado pela dica. Como disse o pequeno projeto inicialmente não tinha a intenção de ser compartilhado por outros pcs, por isso a decisão pelo Sqlite. Nunca trabalhei com SQL server express, trabalhei mais no Mysql e o Sqlite, e mesmo assim meu conhecimento de SQL é um pouco reduzido. vc sabe me dizer se o SQL server express trabalha com Triggers?

    terça-feira, 14 de abril de 2015 14:34
  • Sim.. Tudo o que o SQLite tem, o SQL Server tem tambem, inclusive com a mesma sintaxe.

    O SQL Server express também é gratuito e voce pode baixa-lo aqui:

    https://msdn.microsoft.com/pt-br/evalcenter/dn434042.aspx

    A grande vantagem é que o SQL Server possui um servidor que controla as requisiçoes e por isso pode gerenciar vários usuarios simultaneos, a grande desvantagem é que ele precisa ser instalado.

    O que é uma vantagem do SQLite é uma desvantagem no SQL Server express e vice-versa.

    Na sintaxe dos comandos os dois sao praticamente identicos.

    Com relaçao ao compartilhamento, aqui esta o conselho da equipe de desenvolvedores do SQLite:

    http://www.sqlite.org/faq.html#q5

    "

    Can multiple applications or multiple instances of the same application access a single database file at the same time?

    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.

    "


    William John Adam Trindade
    Analyste-programmeur
    ----------------------------------------------------------


    terça-feira, 14 de abril de 2015 15:49
    Moderador
  • ok, daqui pra frente. Mas tem mais uma coisa, eu deveria ter dito isto antes; desculpas! Eu preciso que a aplicação rode e, consequentemente, tudo aquilo que diz respeito a ela não precise de instalação. Tenho uma outra aplicação desenvolvida por terceiros, só que o BD é Acces, rodando perfeitamente. No caso SQL Server Express é necessário instalação do servidor SQL assim como é feito no MySQL? desde já agradeço.
    terça-feira, 14 de abril de 2015 18:33
  • >Eu preciso que a aplicação rode e, consequentemente, tudo aquilo que diz respeito a ela não precise de instalação.

    Como eu disse, o ideal é que seja uma base gerenciada como o SQL Server (poderia ser mysql ou postgresql ou oracle). Voce pode usar o SQLite em rede, desde que seja levado em conta que a base nao aceita escritas simultaneas (leituras simultaneas sim)

    >Tenho uma outra aplicação desenvolvida por terceiros, só que o BD é Acces, rodando perfeitamente. 

    Quantos usuarios? Access corrompe facilmente com mais de 3 usuarios simultaneos.

    >No caso SQL Server Express é necessário instalação do servidor SQL assim como é feito no MySQL?

    Sim.. exatamente isso. Precisa instalar... mas existe a opçao de criar uma linha de comando para a instalaçao para que ela seja feita de modo automatico.

    att


    William John Adam Trindade
    Analyste-programmeur
    ----------------------------------------------------------


    terça-feira, 14 de abril de 2015 19:23
    Moderador