1. Este site usa cookies. Ao continuar a usar este site está a concordar com o nosso uso de cookies. Saber Mais.

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

Discussão em 'Programação' iniciada por peter alien, 5 de Outubro de 2012. (Respostas: 4; Visualizações: 1286)

  1. peter alien

    peter alien Power Member

    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.
     
    Última edição: 5 de Outubro de 2012
  2. fmf1966

    fmf1966 Power Member

    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.
     
  3. 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).
     
  4. fmf1966

    fmf1966 Power Member

    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.
     
  5. xBoShY

    xBoShY Power Member

    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, ...
     
    Última edição: 7 de Outubro de 2012

Partilhar esta Página