Como desenvolver e implantar continuamente um aplicativo de banco de dados Access 2010
Skill.accdb
.
Estou na fase em que quero começar a implantá-lo para que os usuários possam começar a usá-lo e continuar a desenvolver ao mesmo tempo.
Estive a ler
- MSAccess-Implantação-Melhores Práticas,
- Implay-an-Access-2007-application, and
- Ways-to-share-an-Access-database
que falam em dividir, compilar, instalar, etc., mas eles têm muito poucos procedimentos a seguir.
dividi a minha aplicação de base de dados numa extremidade traseira e numa extremidade dianteira: Skill_Back.accdb
e Skill_Front.accdb
.
O back-end está em uma unidade compartilhada de rede e alguns usuários têm cópias do front-end.
Até agora tudo bem, especialmente se nunca mais tiver de fazer mais desenvolvimento.
Mas não consigo ver como continuar o desenvolvimento sem perturbar o back-end "ao vivo".
como é que eu tenho uma versão de desenvolvimento do front-end a apontar para uma versão falsa do back-end para que eu não estrague a versão ao vivo? E então, quando Eu desejo lançar uma nova versão do front-end, como eu faço com que ele aponte novamente para a versão ao vivo do back-end?
Se eu voltar a dividir (ou seja, usar a ferramenta Mover dados | aceder à base de dados de novo) para apontar para uma extremidade traseira do manequim ainda não existente, disseram-me que todas as tabelas estão agora vazias -- não é o que eu quero. Se eu voltar a dividir para apontar para uma cópia do back-end ao vivo, me perguntam se eu quero substituí - lo -- também não o que Eu quero. Se o fizer, novamente me dizem que " não há tabelas nesta base de dados. A base de dados de fundo estará vazia."e ainda assim vejo que (a frente) ainda está apontando para o back-end ao vivo!
que conceito crítico/ferramenta/procedimento estou a perder? (Eu não estou perguntando sobre compilar ou executar ou construir um instalador -- esses são problemas posteriores.)
Adenda
Depois de seguir o conselho na resposta fina abaixo, encontrei alguns outros artigos que descrever os procedimentos:3 answers
Uma estratégia que uso é a "versão" das minhas Front-ends, e quando lido com bases de dados não USO a ferramenta access' built-in Move Data
.
Como é que eu tenho uma versão de desenvolvimento da front-end apontando para um versão falsa do back-end para que eu não estrague a vida versão?
Você precisa (no mínimo) 2 ambientes diferentes
- produção (o que os seus utilizadores usam)
- teste (onde faz as suas alterações e as testa)
Para testes, precisas do teu próprio back-end e front-end. É aqui que você vai fazer o seu desenvolvimento contínuo. Você nunca quer perturbar o que seus usuários estão trabalhando com, especialmente os dados.
Para a produção, você pode fazer as suas alterações e lançar a nova versão através de uma unidade de rede partilhada, onde os utilizadores podem baixar a cópia, tal como a primeira. Aqui é onde você vai usar o Linked Table Manager
para reconectar as tabelas para o seu back-end de produção e seu novo front-end.
Então o fluxo de trabalho seria:
- Você tem uma produção de back end e front end que os usuários estão usando. Tens uma cópia de ambas as bases de dados para trabalhar, e não está relacionada com o que estão a usar.
- você liga as suas tabelas Frontais à sua versão de desenvolvimento copiadado back-end via
Linked Table Manager
. - Você muda/faz actualizações / continua a desenvolver-se na sua frente .
- testa-os / garante que tudo funciona
- coloque a sua nova versão de produção de front end ( v2 ) na unidade de rede partilhada e ligue - a à produção de back end
- os seus utilizadores descarregam (copy) a nova versão front end e utilizam-na. Eles vêem as tuas mudanças e ficam espantados com o que fizeste e recebes um aumento de $ 5,000 por saberes o que fazer e seres um grande empreendedor.
Gestor De Tabela Associado
Na área de navegação, carregue com o botão direito numa das tabelas ligadas para abrir o menu de atalhos. A partir daí, escolha o Gestor de mesa ligado.
Isso facilita a gestão dos links. Coloque um marcador na caixa ao lado de cada tabela que deseja alterar. Ou se os alterar a todos, carregue em seleccione TODOS . Assinale também a opção "pedir sempre uma nova localização" (no canto inferior esquerdo do a janela de diálogo). Em seguida, o Access irá pedir-lhe para localizar a fonte da base de dados para os links. Se precisar de mais informações, diga alguma coisa.Ligar novas tabelas de trás para a frente
Se eu tivesse uma base de dados com tabelas e quisesse ligar essas tabelas a um front-end no meu desktop, seguiria este processo:
- carregue na página de Dados Externos no topo da fita de acesso
- Clique no Access
- Seleccione o ficheiro correcto Nome / Pasta para o seu back-end
- Seleccionar
Link to the data source by creating a linked table.
- seleccione as tabelas que deseja importar (provavelmente poderá carregar em Seleccionar Tudo) Clica em "OK".
O artigo referencia o Access 2003, mas usei-o para aceder às bases de dados de 2010. Essencialmente, criar um front-end de 2010 compilado e após o arranque, ele verifica se a versão do cliente corresponde à versão do servidor. Se forem diferentes, a nova versão do servidor é copiada para a máquina do cliente. É bonito. liso.
Para a implementação, coloquei a base de dados front-end (FE) (pode ser MDE, MDB ou accdb, funciona com qualquer tipo) numa pasta partilhada, juntamente com um pequeno ficheiro em lote que copia o FE para a pasta %TEMP% do utilizador.
Então Eu só uso o .bat file no ecrã de cada utilizador.
Desta forma, cada vez que um usuário inicia o aplicativo, uma nova cópia do FE é copiada localmente e iniciado.
Para atualizações, Eu só tenho que colocar o novo FE na pasta compartilhada. Isto também elimina a necessidade de compactar regularmente o FE!