Aplicação em MS Access 2010 (melhor método de partilha)

[peter alien]

Boa noite,

tenho uma aplicação feita no MS Access 2010 e queria colocá-la num servidor (Linux) e partilhá-la para ser utilizada por vários utilizadores (Pc's cliente c/ Win7).

A minha questão é esta, qual o melhor formato para se partilhar uma aplicação MS Access ("App1" e "App2" são nomes ficticios):

1) Ficheiro App1.accdb (contendo as tabelas e forms, queries, reports, etc...) no Servidor, e links criados nos computadores-cliente a apontar para esse ficheiro.

2) Ficheiro App1.accdb (contendo só as tabelas) + ficheiro App2.accdb (com as forms, queries, reports, etc... - contendo "Linked Tables" para o ficheiro App1.accdb) no Servidor, e links criados nos computadores-cliente a apontar para o ficheiro App2.

ou

3) Ficheiro App1.accdb (contendo só as tabelas) no Servidor, ficheiro App2.accdb (com as forms, queries, reports, etc... - contendo "Linked Tables") nos computadores-cliente, estando as Linked Tables a apontar para o ficheiro App1.accdb existente no Servidor.



Obrigado.

 

[fmf1966]

Definitivamente a opção 3.

É a que tenho usado, com uma pequena diferença. Mete uma password na app1(servidor) e quando ligares as tabelas à app2 indica a password sem indicá-la aos utilizadores.
Isto porque o utilizador que tenha accesso pela app2 à app1 terá accesso ao local no servidor e poderá abrir as tabelas.
Outra coisa que podes fazer é mudar a extensão da app2.accdb para app2.accdr e assim nenhum menu do Access irá aparecer, nem mesmo o painel de navegação, e este processo é reversivel ao contrário da utilização do .accde que é uma compilação irreversivel.

Não te esqueças de regularmente fazer backup da app1 e ter sempre uma cópia da app2.

 

[hal9000]

Metodo 2, claro!
quando tivers de fazer uma actualização só a fazes num local.
Quanto á "segurança" isso não existe em Access :-), se alguem quiser aceder aos dados e fazer engenharia inversa nada vai impedi-lo(a).

 

[fmf1966]

Metodo 2, claro!
quando tivers de fazer uma actualização só a fazes num local.
Quanto á "segurança" isso não existe em Access :-), se alguem quiser aceder aos dados e fazer engenharia inversa nada vai impedi-lo(a).

Quando quiseres fazer uma actualização nehum utilizador pode ter a applicação aberta.
Quem utilizou esse metodo sabe que é bom ter pouco trafego na rede e mesmo assim vai se tornar muito mais lenta a aplicação.
Quanto à segurança, o pretendido é evitar mexer nos dados sem ser pela app2 e afastar os curiosos, e pelo painel de navegação existe accesso às tabelas ligadas.
Nota que carregar o shift no arranque do *.accdr não para a execução das macros nem existe forma de aceder às opções, como acontece nos *.accdb, mesmo com os mesmo desligados.

 

[xBoShY]

Se tiveres muitos utilizadores a utilizar a aplicação, deverás fazer um controlo de versões.
Crias uma tabela do género: "supported_version" e chutas pra lá as versões da App2 compatíveis com a actual App1.
Ao iniciar a App2 e a cada procedimento da App2, deverás verificar se a versão consta na App1.
Só assim, terás a certeza que o acesso à App1 é feito apenas por App2 de versões compatíveis.

---------

Há alguma razão para usar MS Access como SGBD (ou uma espécie de ^_^)?
Existem SGBD sólidos que são gratuitos! MySQL, por exemplo, é free. Podes continuar a utilizar o Access como frontend fazendo uso de ODBC para te ligares às tabelas MySQL.
Tenho a certeza que muitos dos procedimentos e queries que utilizas podem ser transformadas em stored procedures/views =) Isto poderá reduzir o tempo em que passas de volta do front end (no teu caso, app2), deixando mais tempo para o que interessa (SGBD).

Pequeno exemplo básico:
"Eliminar um produto" (Stored Procedure):
- Hoje, apenas fazes "DELETE FROM produto WHERE...".
- Amanha, apenas queres alterar o produto.estado para "-1".
- Depois de amanha, já não existe o campo produto.estado e o cliente vai para uma tabela chamada "produtos_removidos"

Tens duas opções:
- Manter a App2 atualizada. Isto implica 3 versões diferentes, e a ter que modificar sempre a query "Cliente_remove".
- Chamar a stored procedure: "EXEC cliente_remove <cliente_id>". Aqui a App2 manteve-se igual nas 3 versões, sendo a integração totalmente transparente para os utilizadores finais.

e ainda tens Views, Functions, Triggers, ...