Início
Avelino João 29/5/2013, 16:00O que está "se movendo aplicativo de acesso à nuvem" significa?
Isso significa que você está se movendo seus dados para um banco de dados SQL Server hospedado na web. Você já não tem os dados localmente e você ainda estiver executando a interface de acesso localmente. Você pode ou não ter algumas tabelas local, mas para a maior parte, todos os dados em SQL Server na web.
Porque não usar o Terminal Services?
Para ser justo, os serviços de terminal seria mais rápido e proporcionar uma experiência muito mais suave para os seus usuários. Você pode comprar um aplicativo de desktop remoto para o seu tablet ou telefone e até mesmo remoto, algo que você não pode fazer com um backend hospedado. Às vezes não é possível ir por esse caminho: seu cliente pode não ter os recursos para fazer isso ou é muito caro. Resumindo: se você pode hospedar seu aplicativo em um servidor de terminal que, caso contrário, continue lendo.
Passo 1: Instalar o SQL Server Express local
Você ficaria surpreso com quantas desenvolvedores começar a migrar do Access para a nuvem, como o seu primeiro passo, quando eles deveriam migrar para o SQL Server localmente primeiro. Migrando para o SQL é uma proposta desafiadora para um marinheiro de primeira viagem, você vai precisar alterar seu projecto de banco de dados para incluir campos não presentes no Access, (como o campo RowVersion) ou creat vistas adicionais para cada relatório. Há uma tonelada de coisas que você precisa fazer antes de migrar para a web, e se você optar por enviar o seu primeiro banco de dados para a nuvem, você vai ser prejudicado com uma conexão mais lenta fazendo coisas que você poderia ter sido mais rápido fazer localmente.
Passo 1: Qual versão instalar?
Eu recomendo que você instale o SQL Server Express 2008 R2 com ferramentas, a menos que você esteja certo o seu acolhimento na web está usando o SQL Server 2012. Se você não sabe onde você está indo para hospedar seu banco de dados, do que ir a rota segura e usar de 2008, uma vez que é muito fácil de migrar para o 2012, mas quase impossível fazer o downgrade para 2008.
Passo 2: Optimize seu banco de dados para uso local
Sua migração SQL pode retardar seu banco de dados Access em vez de torná-lo mais rápido. Regra de ouro: Se o banco de dados é lenta no seu local de SQL Server ele só vai ser mais lento na web por muitos factores muito mais. Você deve corrigir problemas de desempenho em sua máquina local antes de enviá-lo para a web. É por isso que eu vim com este blog, para ajudar os outros migrar sem tropeçar no caminho. Se você não está feliz com o desempenho local, não actualize para a web até que seja optimizado.
Passo 3: Use SQL Server Security com uma tabela de usuário
Você não pode usar a segurança do Microsoft Access na nuvem, então você precisa usar o SQL Server Security, juntamente com uma tabela do usuário. Por quê?
Porque muitas empresas de hospedagem só irá fornecer uma quantidade limitada de usuários do SQL Server para o seu aplicativo, geralmente 1-5 usuários max. Isso não vai funcionar com uma lista de usuários, de 6 ou mais, então você está preso com a mesma abordagem de um sítio web designer usaria: Criar uma tabela de usuários com nomes de usuários e senhas e autenticar os usuários quando fazem o logon contra a mesa. (Outra vantagem Terminal Server tem contra a nuvem, em servidores de terminal, você pode usar a segurança do Active Directory).
Sob este esquema de segurança você só terá um login do SQL Server que possui direitos sobre todas as tabelas. Use-o para vincular tabelas para o seu frontend e ao fazer conexões com ADODB a partir do código. A tarde será necessário armazenar as credenciais em seu código, que também tem as suas desvantagens: Qualquer um pode abrir seu banco de dados de acesso com um editor de texto e descobrir sua senha. Evitamos a questão embaralhando o nome de usuário e senha no código.
Passo 4: Carregue o seu banco de dados
Você está finalmente pronto para fazer upload de seu banco de dados para o host, feito principalmente por fazer backup de seu banco de dados local e, em seguida, enviar o arquivo para o seu hoste para eles para restaurar. Eles podem ou não permitir que você mantenha o seu nome do banco de dados actual, para estar pronto para mudar seu código, conforme necessário, uma vez que é carregado.
Passo 5: Optimize novamente, e novamente, e novamente
Agora que você está de banco de dados na nuvem que você pode ou não pode ter problemas de desempenho: Os formulários podem demorar muito tempo, os relatórios de tempo limite e, em geral, sua aplicação pode ser inútil, levando-o a questionar por que você fez isso em primeiro lugar. Como não há maneira de saber como o seu aplicativo irá executar na web até que você realmente fazer o upload, você precisará novamente fazer mais uma rodada de ajuste de desempenho para obter a sua aplicação até uma velocidade aceitável, mas o quanto isso vai exigir de você? Infelizmente, determinando um desempenho aceitável é muito subjectivo. Você pode decidir que é ok, mas uma vez que seu cliente recebe suas patas sobre ela podem discordar. Em geral, eu recomendo o desempenho ok se é 15 segundos ou menos, 2-3 segundo sendo um padrão e um segundo que é ideal. É ok se os relatórios demorar mais tempo, mas qualquer coisa de mais de 30 segundos, irá começar a roer as pessoas.
Optimização em função do retorno em declínio contra o seu tempo
Quanto mais tempo você colocar em optimização do cada vez menos retorno você recebe por isso. Na primeira você vai conseguir grandes resultados para seus esforços, adicionando índices adicionais, a criação de associações, o descarregamento de trabalho para o servidor, a criação de procedimentos armazenados, etc, mas esses esforços vai trazer de volta cada vez menos de um retorno sobre o desempenho contra o tempo investido, deixando você com a escolha de quanto mais você vai colocar nele até que o desempenho é aceitável. É por esta razão que nós garantir que os nossos clientes a entender o quão difícil pode ser a de acertar, você simplesmente não sabe o quanto de optimização que vai exigir até que sejam satisfeitas.
Isso pode ser feito, fazemos isso o tempo todo
Eu não quero enganá-lo, é possível, mas não é fácil. Dê o melhor de si, aprender a "nuvem permitem" seu aplicativo Access, e seu será recompensado com um novo conjunto de habilidades como qualquer outro.
Analise do Especialista em Ms Access e SQL Server
Juan Soto
http://accessexperts.net/
Isso significa que você está se movendo seus dados para um banco de dados SQL Server hospedado na web. Você já não tem os dados localmente e você ainda estiver executando a interface de acesso localmente. Você pode ou não ter algumas tabelas local, mas para a maior parte, todos os dados em SQL Server na web.
Porque não usar o Terminal Services?
Para ser justo, os serviços de terminal seria mais rápido e proporcionar uma experiência muito mais suave para os seus usuários. Você pode comprar um aplicativo de desktop remoto para o seu tablet ou telefone e até mesmo remoto, algo que você não pode fazer com um backend hospedado. Às vezes não é possível ir por esse caminho: seu cliente pode não ter os recursos para fazer isso ou é muito caro. Resumindo: se você pode hospedar seu aplicativo em um servidor de terminal que, caso contrário, continue lendo.
Passo 1: Instalar o SQL Server Express local
Você ficaria surpreso com quantas desenvolvedores começar a migrar do Access para a nuvem, como o seu primeiro passo, quando eles deveriam migrar para o SQL Server localmente primeiro. Migrando para o SQL é uma proposta desafiadora para um marinheiro de primeira viagem, você vai precisar alterar seu projecto de banco de dados para incluir campos não presentes no Access, (como o campo RowVersion) ou creat vistas adicionais para cada relatório. Há uma tonelada de coisas que você precisa fazer antes de migrar para a web, e se você optar por enviar o seu primeiro banco de dados para a nuvem, você vai ser prejudicado com uma conexão mais lenta fazendo coisas que você poderia ter sido mais rápido fazer localmente.
Passo 1: Qual versão instalar?
Eu recomendo que você instale o SQL Server Express 2008 R2 com ferramentas, a menos que você esteja certo o seu acolhimento na web está usando o SQL Server 2012. Se você não sabe onde você está indo para hospedar seu banco de dados, do que ir a rota segura e usar de 2008, uma vez que é muito fácil de migrar para o 2012, mas quase impossível fazer o downgrade para 2008.
Passo 2: Optimize seu banco de dados para uso local
Sua migração SQL pode retardar seu banco de dados Access em vez de torná-lo mais rápido. Regra de ouro: Se o banco de dados é lenta no seu local de SQL Server ele só vai ser mais lento na web por muitos factores muito mais. Você deve corrigir problemas de desempenho em sua máquina local antes de enviá-lo para a web. É por isso que eu vim com este blog, para ajudar os outros migrar sem tropeçar no caminho. Se você não está feliz com o desempenho local, não actualize para a web até que seja optimizado.
Passo 3: Use SQL Server Security com uma tabela de usuário
Você não pode usar a segurança do Microsoft Access na nuvem, então você precisa usar o SQL Server Security, juntamente com uma tabela do usuário. Por quê?
Porque muitas empresas de hospedagem só irá fornecer uma quantidade limitada de usuários do SQL Server para o seu aplicativo, geralmente 1-5 usuários max. Isso não vai funcionar com uma lista de usuários, de 6 ou mais, então você está preso com a mesma abordagem de um sítio web designer usaria: Criar uma tabela de usuários com nomes de usuários e senhas e autenticar os usuários quando fazem o logon contra a mesa. (Outra vantagem Terminal Server tem contra a nuvem, em servidores de terminal, você pode usar a segurança do Active Directory).
Sob este esquema de segurança você só terá um login do SQL Server que possui direitos sobre todas as tabelas. Use-o para vincular tabelas para o seu frontend e ao fazer conexões com ADODB a partir do código. A tarde será necessário armazenar as credenciais em seu código, que também tem as suas desvantagens: Qualquer um pode abrir seu banco de dados de acesso com um editor de texto e descobrir sua senha. Evitamos a questão embaralhando o nome de usuário e senha no código.
Passo 4: Carregue o seu banco de dados
Você está finalmente pronto para fazer upload de seu banco de dados para o host, feito principalmente por fazer backup de seu banco de dados local e, em seguida, enviar o arquivo para o seu hoste para eles para restaurar. Eles podem ou não permitir que você mantenha o seu nome do banco de dados actual, para estar pronto para mudar seu código, conforme necessário, uma vez que é carregado.
Passo 5: Optimize novamente, e novamente, e novamente
Agora que você está de banco de dados na nuvem que você pode ou não pode ter problemas de desempenho: Os formulários podem demorar muito tempo, os relatórios de tempo limite e, em geral, sua aplicação pode ser inútil, levando-o a questionar por que você fez isso em primeiro lugar. Como não há maneira de saber como o seu aplicativo irá executar na web até que você realmente fazer o upload, você precisará novamente fazer mais uma rodada de ajuste de desempenho para obter a sua aplicação até uma velocidade aceitável, mas o quanto isso vai exigir de você? Infelizmente, determinando um desempenho aceitável é muito subjectivo. Você pode decidir que é ok, mas uma vez que seu cliente recebe suas patas sobre ela podem discordar. Em geral, eu recomendo o desempenho ok se é 15 segundos ou menos, 2-3 segundo sendo um padrão e um segundo que é ideal. É ok se os relatórios demorar mais tempo, mas qualquer coisa de mais de 30 segundos, irá começar a roer as pessoas.
Optimização em função do retorno em declínio contra o seu tempo
Quanto mais tempo você colocar em optimização do cada vez menos retorno você recebe por isso. Na primeira você vai conseguir grandes resultados para seus esforços, adicionando índices adicionais, a criação de associações, o descarregamento de trabalho para o servidor, a criação de procedimentos armazenados, etc, mas esses esforços vai trazer de volta cada vez menos de um retorno sobre o desempenho contra o tempo investido, deixando você com a escolha de quanto mais você vai colocar nele até que o desempenho é aceitável. É por esta razão que nós garantir que os nossos clientes a entender o quão difícil pode ser a de acertar, você simplesmente não sabe o quanto de optimização que vai exigir até que sejam satisfeitas.
Isso pode ser feito, fazemos isso o tempo todo
Eu não quero enganá-lo, é possível, mas não é fácil. Dê o melhor de si, aprender a "nuvem permitem" seu aplicativo Access, e seu será recompensado com um novo conjunto de habilidades como qualquer outro.
Analise do Especialista em Ms Access e SQL Server
Juan Soto
http://accessexperts.net/
