Migração do banco de dados do Access 2002 para o SQL Server

Adam Cogan - Diretor regional da Microsoft, Austrália

Dezembro de 2004

Aplica-se a:

Microsoft Access 2002
Microsoft SQL Server 2000 Service Pack 3a (SP3a)

Resumo: Use esta comparação de recursos na preparação da migração do banco de dados back-end do Access 2002 para o SQL Server 2000. Este artigo também contém links para páginas em inglês. (37 páginas impressas)

Nesta página

Pré-requisitos
Introdução
Ferramentas do SQL Server
Arquitetura
Escalabilidade e desempenho
Trabalhando com dados
Conclusão
Glossário

Pré-requisitos

Todas as comparações contidas neste documento são feitas pressupondo-se o uso dos seguintes softwares:

Microsoft Access 2002 ou posterior
Microsoft SQL Server 2000 Standard Edition ou Enterprise Edition

Também se pressupõe que os seus dados estejam armazenados em um arquivo de banco de dados do Access (.mdb), e não no SQL Server, e que você não esteja usando um ADP (projeto de dados do Access) que ofereça suporte a muitos dos recursos do SQL Server descritos neste documento.

Quem deve ler este documento

Este documento tem como público-alvo desenvolvedores do Access, desenvolvedores do Microsoft Visual Basic e desenvolvedores do .NET familiarizados com os recursos do Access e que estejam pensando na possibilidade de migrar sua infra-estrutura de back-end (dados e consultas) para o Microsoft SQL Server.

Os leitores precisam estar familiarizados com estes recursos do Access:

SQL Básico
Importação e exportação de dados em vários formatos
Backup e restauração de dados
Implementação de segurança

Este documento foi criado para ajudar os novos desenvolvedores do SQL Server a comparar os recursos do Access e do SQL Server.

Inicio da pagina

Introdução

Geralmente, os desenvolvedores do Microsoft Access pensam em migrar para o SQL Server por razões de desempenho, segurança e estabilidade. Esse processo é conhecido como upsizing e os desenvolvedores encontrarão algumas diferenças fundamentais ao migrar do Access para o SQL Server. É essencial que essas diferenças sejam notadas e que se tomem as devidas providências para garantir uma migração perfeita e sem incidentes.

O Microsoft SQL Server é um sistema de gerenciamento de dados de nível corporativo. Ele inclui segurança, escalabilidade e flexibilidade de gerenciamento padrão da indústria. Além disso, há suporte para XML e consultas na Internet.

Dica: o processo de migração do Access para o SQL Server não é abordado aqui.

Para obter mais informações sobre migração, consulte Migrating Your Access Database to Microsoft SQL Server 7.0 (em inglês). (Observação: este artigo foi escrito para o SQL Server 7.0 e não foi atualizado.)

Dica: as diferenças entre replicação de dados e segurança do banco de dados não são abordadas aqui.
Para obter mais informações sobre como implementar replicação no SQL Server, consulte Implementing Replication (em inglês) na documentação do SDK do SQL Server 2000.
Para obter mais informações sobre segurança no SQL Server, consulte Managing Security Accounts (em inglês) na documentação do SDK do SQL Server 2000.

Inicio da pagina

Ferramentas do SQL Server

Usando o menu principal da janela de banco de dados do Access, você pode criar uma consulta, projetar um banco de dados ou pesquisar dados. Para exportar dados do banco de dados, clique em Arquivo e em Exportar. Para importar dados do banco de dados, clique em Arquivo, em Obter Dados Externos e em Importar.

O SQL Server fornece um conjunto de ferramentas poderosas que simplifica o processo de navegação, consulta, importação e exportação de dados. São elas:

SQL Server Enterprise Manager
SQL Server Query Analyzer
Data Transformation Services
SQL Server Profiler

Ferramentas do SQL Server para criar bancos de dados e consultas, bem como pesquisar dados

Com o SQL Server, você usa duas ferramentas para executar tarefas de manutenção do banco de dados, bem como pesquisar dados e editá-los. São elas o SQL Server Enterprise Manager e o SQL Server Query Analyzer. Os desenvolvedores de formulários do Access que planejam migrar seus formulários para o .NET acharão o Microsoft Visual Studio .NET útil, pois ele oferece uma maneira integrada de criar e gerenciar o banco de dados do SQL Server e os formulários de acesso a dados no mesmo ambiente de desenvolvimento.

SQL Server Enterprise Manager

O SQL Server Enterprise Manager é o aplicativo incorporado ao SQL Server para criar e gerenciar bancos de dados, como mostra a Figura 1, bem como navegar pelos dados, como mostra a Figura 2. O Enterprise Manager também fornece funcionalidade para:

Gerenciar tabelas, campos e dados; relacionamentos de tabelas; procedimentos armazenados; modos de exibição; disparadores; funções; e tipos de dados definidos pelo usuário.
Criar diagramas de banco de dados.
Criar backups dos bancos de dados e restaurar dados.
Gerenciar logons e permissões de objeto do banco de dados.
Importar e exportar dados em vários formatos que usem o DTS (Data Transformation Services).

Figura 1. O SQL Server Enterprise Manager substitui a caixa de diálogo principal para criação e gerenciamento de bancos de dados do Access.

Figura 2. Use o Enterprise Manager para pesquisar dados e editá-los como no Access.

SQL Server Query Analyzer

O SQL Server Query Analyzer é uma ferramenta de consulta gráfica completa que substitui o principal designer de consulta do Access. Ele permite:

Criar e depurar consultas.
Executar várias consultas simultâneas.
Exibir dados.
Exportar dados. Para isso, basta clicar em Query (Consulta) e em Results to File (Resultado em arquivo).
Otimizar consultas. Para isso, basta clicar em Query (Consulta) e em Show Execution Plan (Mostrar plano de execução).
Depurar consultas avançadas. Para isso, basta clicar em Tools, em Object Browser (Pesquisador de objetos) e em Debug (Depurar).

Dica: o Query Analyzer oferece suporte aos recursos descritos anteriormente e fornece realce de sintaxe para facilitar a exibição e a depuração de consultas, como mostra a Figura 3. Embora você possa gravar procedimentos armazenados no Enterprise Manager, como mostra a Figura 4, os desenvolvedores do Access acharão o Query Analyser mais rico em recursos.

Figura 3. O Query Analyzer substitui o designer de consulta do Access e adiciona recursos, como realce de sintaxe e depuração de consultas.

Figura 4. Criar procedimentos armazenados avançados no Enterprise Manager não é tão fácil quanto no Query Analyzer

O recurso Criar Consulta Usando o Assistente do Access não tem equivalente no SQL Server. Você deve criar consultas usando o designer de consulta ou as instruções do SQL Server.

Visual Studio .NET

Com o Visual Studio .NET, você pode gerenciar o banco de dados e seus objetos praticamente da mesma maneira que o faz com o Enterprise Manager, como mostra a Figura 5. Dependendo de sua versão do Visual Studio .NET, você pode criar um projeto de banco de dados que permita:

Criar e executar procedimentos armazenados, modos de exibição, disparadores e funções.
Pesquisar tabelas.
Exibir dados.

Esse recurso é útil para desenvolvedores do .NET, pois oferece um método integrado de gerenciamento de bancos de dados. Os desenvolvedores podem criar aplicativos e gerenciar bancos de dados em um único aplicativo.

Figura 5. O Visual Studio .NET fornece uma maneira integrada de gerenciar dados

Para obter mais informações sobre quais versões do Visual Studio .NET oferecem suporte a que recursos de gerenciamento de banco de dados, consulte Visual Database Tools Editions (em inglês).

Ferramentas do SQL Server para importar e exportar dados

Data Transformation Services

O DTS (Data Transformation Services) permite importar dados de/exportar dados para várias fontes de dados que usam uma arquitetura baseada em banco de dados OLE, como o Microsoft Excel. O DTS substitui as funções de importação e exportação do Access (como mostra a Figura 7) e também oferece funcionalidade para:

Exportar dados para/importar dados de outro banco de dados SQL Server.
Exportar e importar dados em vários formatos, como Excel (arquivos .xls), valores separados por vírgula (arquivos .csv) e Microsoft Access (consulte a Figura 6).
Executar transformações nos dados.

Figura 6. Use o DTS para importar e exportar dados em vários formatos.

O DTS é mais eficiente do que os comandos de importação e exportação do Access. Muitas tarefas executadas em um processo de importação do Access em várias etapas (por exemplo, popular tabelas temporárias e executar várias consultas para fazer a transformação) podem ser executas no DTS em apenas uma etapa. Você pode executar transformações de dados, como copiar dados de uma tabela para outra usando uma consulta SQL ou executar código VBScript para transformar partes dos dados antes da inserção na tabela de destino, como mostra a Figura 8.

Figura 7. O DTS substitui os assistentes de importação e exportação do Access e permite transformações de dados eficientes.

Figura 8. O DTS executa transformações eficientes nos dados que demorariam muito mais no Access.

SQL Server Profiler

O SQL Server Profiler é uma ferramenta essencial de otimização do desempenho do banco de dados. Ele é especialmente útil após a migração de um sistema somente cliente, como o Access. Ele exibe todos os comandos executados no servidor, como conexões abertas e fechadas e transações do banco de dados, como mostra a Figura 9. Isso ajuda a identificar as transações especialmente longas ou que consomem muitos recursos.

Figura 9. O SQL Server Profiler monitora a atividade do banco de dados para ajudar na otimização do desempenho.

Para obter mais informações sobre como usar as ferramentas do SQL Server, consulte Migrating Your Access Database to Microsoft SQL Server 7.0 (em inglês). (Observação: este artigo foi escrito para o SQL Server 7.0 e não foi atualizado.)

Inicio da pagina

Arquitetura

Há várias diferenças, semelhanças e desvantagens entre a arquitetura do Access e do SQL Server. As diferenças estão em:

Modelos de acesso a dados.
Design de tabela.
Relacionamentos.
Indexação.
Tipos de consulta de dados.
O SQL Server também inclui ferramentas eficientes para otimizar e simplificar a manipulação de dados, incluindo:
Disparadores.
Tabelas temporárias.
Funções definidas pelo usuário.

Requisitos do sistema

Requisitos mínimos do sistema

Como o SQL Server tem mais recursos e é mais escalonável do que o Access, ele exige um pouco mais de requisitos do sistema. A Tabela 1 compara os requisitos mínimos entre os dois sistemas.

Tabela 1. Requisitos mínimos do sistema para o SQL Server e o Access

	Access	SQL Server
Processador	Pentium 75 MHz	Pentium 166 MHz
Memória	8 MB, mais 4 MB para cada aplicativo executando simultaneamente, e mais 128 MB para o Microsoft Windows XP	128 MB de RAM ou mais
Espaço no disco rígido	30 MB	270 MB (instalação completa)
Sistema operacional	Microsoft Windows Server 2003, Windows XP, Windows 2000, Windows NT 4.0 com Service Pack 6 (SP6), Windows Millennium Edition, Windows 98 Segunda Edição, Windows 98 ou Windows 95	Microsoft Windows Server 2003, Windows XP, Windows 2000, Windows NT 4.0, Windows 98 Segunda Edição, Windows 98, Windows 95 ou Windows CE

Requisitos realistas do sistema

Os requisitos mínimos listados na Tabela 1 não são realistas em um ambiente operacional comum. Os requisitos do sistema dependem principalmente da quantidade de dados e do número de usuários simultâneos.

Em um cenário de 10 usuários simultâneos em um banco de dados de 1 GB, o sistema especificado na Tabela 2 é o recomendado para executar o Access ou o SQL Server em um ambiente de produção.

Tabela 2. Requisitos recomendados do sistema para o SQL Server e o Access

	Recomendado
Processador	Pentium III 650 MHz
Memória	384 MB
Espaço no disco rígido	2 GB
Sistema operacional	Microsoft Windows Server 2003 ou Windows 2000

Versões do SQL Server

O SQL Server 2000 está disponível em seis edições:

Enterprise
Standard
Personal
Developer
Desktop Engine (MSDE)
SQL Server CE (uma versão compatível com o Windows CE)

A Tabela 3 mostra os requisitos de sistema operacional para as diferentes edições do SQL Server.

Tabela 3. Requisitos de sistema operacional para as diferentes edições do SQL Server

Sistema operacional	Enterprise Edition	Standard Edition	Personal Edition	Developer Edition	Desktop Engine (MSDE)	SQL Server CE
Windows Server 2003, Standard Edition	Sim	Sim	Sim	Sim	Sim	Não
Windows Server 2003, Enterprise Edition	Sim	Sim	Sim	Sim	Sim	Não
Windows Server 2003, Datacenter Edition	Sim	Sim	Sim	Sim	Sim	Não
Windows XP Professional	Não	Não	Sim	Sim	Sim	Não
Windows CE	Não	Não	Não	Não	Não	Sim
Windows 9x	Não	Não	Sim	Não	Sim	Não

Implementação do mecanismo

O mecanismo de bancos de dados Jet do Access é diferente no SQL Server, pois ele não é permanentemente executado como um serviço, como acontece no SQL Server, mas iniciado cada vez que um usuário abre um arquivo de banco de dados Jet (arquivo .mdb) usando o Access ou algum outro método de acesso a dados. Quando um usuário fecha um arquivo .mdb e o arquivo não está mais em uso, o mecanismo Jet é descarregado da memória.

A principal diferença é que, se não houver usuários acessando o arquivo .mdb, será possível copiá-lo ou movê-lo para outro local usando o Windows. No caso do SQL Server, o seu serviço está constantemente em execução e está conectado aos arquivos de banco de dados do SQL Server (arquivo .mdf) registrados com ele. Para copiar um arquivo .mdf, você precisa parar o serviço do SQL Server ou desanexar o arquivo .mdf do serviço atual para poder movê-lo.

Modelos de acesso a dados

O Access é um RDBMS (sistema de gerenciamento de banco de dados relacional) somente cliente. Isso significa que todo o processamento de dados, como classificação e filtragem, é feito em um único computador.

Geralmente, os desenvolvedores de Access tentam emular o método cliente/servidor dividindo o banco de dados. Em um ambiente no qual vários usuários usam o Access simultaneamente, normalmente instala-se um banco de dados do Access em cada computador cliente. Esse banco de dados contém formulários, relatórios, consultas salvas e código de formulário do Microsoft VBA (Visual Basic for Applications). Todos os dados são mantidos em um banco de dados do Access em um servidor central e são devolvidos às máquinas cliente quando solicitados. Esse cenário exige muitos recursos da rede e do cliente. Essa estrutura é mostrada na Figura 10.

Figura 10. Divisão de banco de dados do Access (o vermelho indica a carga de trabalho)

Nesse cenário, não há processamento de dados no servidor. Quando um cliente solicita dados, todo o conjunto de dados é enviado a ele através da rede e qualquer processamento é feito na máquina cliente.

Por exemplo, uma financeira tem um banco de dados com um milhão de registros em sua tabela Contas a Receber (arquivo .mdb do Access). Um aplicativo do Access quer exibir a soma total das contas a receber (um campo calculado). Para isso, o Access tem que transferir a tabela inteira pela rede e executar os cálculos na estação de trabalho.

Isso pode causar sérios problemas de desempenho no servidor e na rede. Várias solicitações de grandes quantidades de dados consumirão recursos do servidor, e transferir conjuntos inteiros de dados por uma conexão de rede a deixará consideravelmente mais lenta.

O SQL Server, no entanto, é um RDBMS cliente/servidor puro. Isso significa que o cliente e o servidor compartilham a carga de processamento. O cliente (por exemplo, um aplicativo do .NET Windows) envia uma solicitação de dados com qualquer parâmetro e o servidor executa qualquer classificação e filtragem e devolve ao cliente apenas o conjunto filtrado de dados. Essa estrutura é mostrada na Figura 11.

Figura 11. O SQL Server ajuda a reduzir o tráfego da rede e a carga do servidor por meio da distribuição de tarefas de processamento entre o cliente e o servidor.

Como o SQL Server processa toda a filtragem e a classificação no servidor, apenas o conjunto de resultados especificado é retornado. Isso ajuda a reduzir o tráfego da rede de forma significativa, pois há uma transferência menor de dados entre cliente e servidor. Isso também ajuda a reduzir o volume de processamento do servidor, pois ele não precisa retornar tantos registros quanto precisaria no Access.

Tipos de dados

Há várias diferenças nos tipos de dados entre o Access e o SQL Server. A maioria desses tipos de dados é automaticamente convertida durante o upsizing, embora seja importante verificar isso no banco de dados do SQL Server após o upsizing. A Tabela 4 mostra as diferenças nos tipos de dados entre o Access e o SQL Server. Observe que também há alguns tipos de dados sem suporte.

Tabela 4. Comparação de tipos de dados entre o Access e o SQL Server

Jet (Access)	SQL Server
Texto	char, nchar, varchar, nvarchar
Memorando	text, ntext
Byte	tinyint
Inteiro	smallint
Inteiro Longo	integer
Simples	real
Duplo	float
Código de Replicação	uniqueidentifier
Decimal	decimal
Data/Hora	smalldatetime, datetime, timestamp
Moeda	smallmoney, money
AutoNumeração	int + identity property
Sim/Não	bit
Objeto OLE	image
Hiperlink	<sem equivalente>
<sem equivalente>	binary, varbinary

Dica: no Access, as colunas de numeração automática são geradas automaticamente assim que o usuário começa a editar um novo registro. No SQL Server, a numeração automática é gerada somente quando o registro é salvo. Cuidado ao recriar qualquer lógica existente que dependa do valor da numeração automática no Access.

Tipos de dados definidos pelo usuário

O SQL Server permite definir tipos de dados personalizados, chamados de UDDTs (tipos de dados definidos pelo usuário). Os UDDTs têm como base os tipos de dados já existentes no SQL Server. Além disso, é possível adicionar restrições diretamente aos tipos para:

Especificar um valor padrão. (Um valor que será inserido automaticamente em um campo se nenhum valor for especificado para esse registro.)
Definir o tamanho máximo do campo.
Definir se o campo pode ser nulo.

Os UDDTs tornam-se sem valor ao especificar campos em tabelas cujas propriedades possam mudar no futuro. Por exemplo, se você definisse um campo de identificador exclusivo cujo tipo de dados base do SQL Server fosse varchar(15) (seqüência de 15 caracteres) e definisse todos os procedimentos armazenados relacionados para aceitar um parâmetro do tipo varchar(15), alterar o comprimento ou o tipo de dados do campo se tornaria um grande problema de manutenção. Todos os procedimentos armazenados e as tabelas precisariam ser alterados para refletir as mudanças no tipo de dados.

Uma solução melhor seria criar um UDDT chamado "CodeType", por exemplo, e definir o comprimento e o tipo de dados base no UDDT. Todos os procedimentos armazenados e as definições de tabela usariam esse UDDT; portanto, se o tamanho do campo aumentasse, bastaria alterar a definição do UDDT.

Os UDDTs são definidos por meio do Enterprise Manager, como mostra a Figura 12.

Figura 12. Especificando UDDTs para usar em objetos de banco de dados do SQL Server

Design de tabela

As tabelas são representadas de forma semelhante no Access e no SQL Server. Ambos os DBMSs (sistemas de gerenciamento de banco de dados) são relacionais, ou seja, dados relacionados são armazenados em tabelas lógicas vinculadas por identificadores exclusivos. A interface de design de tabela é semelhante no Access e no SQL Server, como mostra a Figura 13.

Figura 13. Design semelhante de tabelas no Access e no SQL Server

Relacionamentos

No Access, você pode especificar regras para os campos das tabelas, por exemplo, quando um valor em uma tabela for alterado, os valores nas tabelas relacionadas serão automaticamente atualizados (atualização em cascata).

No SQL Server, é possível criar as mesmas regras por meio do designer de diagrama do Enterprise Manager (como mostra a Figura 14). O SQL Server oferece suporte a cinco classes de restrições:

NOT NULL. Especifica que a coluna não pode conter um valor NULL.

CHECK. Restringe os valores que podem ser inseridos em uma coluna. O código a seguir cria uma tabela Employee que adiciona uma restrição CHECK ao campo Salary para que o valor esteja entre 10.000 e 1.000.000.

CREATE TABLE Employee
    (
    EmployeeID          int        PRIMARY KEY,
    Name               char(50),
    Address          char(50),
    Salary         money,
    CONSTRAINT chk_Salary CHECK (Salary BETWEEN 10000 and 1000000)
       )

UNIQUE. Garante que todos os valores de uma coluna da tabela sejam exclusivos. É usado normalmente em colunas de identificação.
PRIMARY KEY. Identifica a coluna ou um conjunto de colunas cujos valores identificam uma linha da tabela de forma exclusiva.

FOREIGN KEY. Estabelece os relacionamentos entre tabelas. O código a seguir cria uma tabela EmployeePosition que faz referência a EmployeeID na tabela Employee criada anteriormente.

CREATE TABLE EmployeePosition
    (
    EmployeePositionID    int        PRIMARY KEY,
    EmployeeID           int        FOREIGN KEY
                                     REFERENCES Employee(EmployeeID)
         ON DELETE CASCADE
    Position          char(50)
    )

Figura 14. O SQL Server oferece suporte a relacionamentos semelhantes aos do Access

A cláusula ON DELETE tem duas opções:

CASCADE. Especifica que, se o registro de um funcionário for excluído da tabela Employee, qualquer registro com um EmployeeID correspondente na tabela EmployeePosition também será excluído.
NO ACTION. Especifica que o registro EmployeePosition não será afetado se o registro pai usado como referência na tabela Employee for excluído.

O SQL Server também oferece suporte à cláusula ON UPDATE, que especifica a ação a ser realizada se um registro pai for atualizado. Ele também oferece suporte às opções CASCADE e NO ACTION.

Lembre-se de que os relacionamentos no SQL Server não são tão flexíveis quanto no Access. No Access, você pode:

Atualizar em cascata, atualizar ou fazer uma atualização de exclusão de uma tabela para ela mesma.
Atualizar em cascata, atualizar ou fazer uma atualização de exclusão de chaves externas em uma tabela na qual a propriedade Required esteja definida como Yes.

Embora o SQL Server não ofereça suporte a essas duas opções, isso pode levar a bancos de dados mais robustos e com menos probabilidade de problemas de relacionamento e de chave.

Referências circulares na atualização em cascata sem suporte

Ao contrário do Access, o SQL Server não permite integridade referencial circular. Digamos, por exemplo, que haja um funcionário de nível sênior no departamento de vendas de uma empresa. No banco de dados, o Employee Type do funcionário é Senior e Category é Sales. No entanto, no banco de dados, o Employee Type Senior está na Sales Category. Como mostra a Figura 15, a estrutura do banco de dados que permite isso cria uma referência circular que o SQL Server não permite. Se tentar criar restrições de atualização circulares, você receberá algo semelhante a este erro:

Unable to create relationship 'FK_EmployeeType_Employee'.  
ODBC error: [Microsoft][ODBC SQL Server Driver][SQL Server]Introducing 
FOREIGN KEY constraint 'FK_EmployeeType_Employee' on table 'EmployeeType' 
may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or 
ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.
[Microsoft][ODBC SQL Server Driver][SQL Server]Could not create 
constraint. See previous errors.

Isso acontece porque há a possibilidade de causar um loop infinito se um campo for atualizado em qualquer uma das tabelas. Neste exemplo, atualizar um campo CategoryID fará com que o próximo campo CategoryID seja atualizado (devido à integridade referencial da atualização em cascata), o que faria com que o próximo campo CategoryID fosse atualizado e assim sucessivamente.

Figura 15. Restrições de atualização em cascata circular causam erros no SQL Server.

Para contornar esse problema no SQL Server, você terá que remover as restrições de integridade referencial das tabelas e criar um disparador em cada uma delas para executar as atualizações. Para obter mais informações sobre como usar disparadores, consulte Enforcing Business Rules with Triggers (em inglês).

Aprimoramentos na indexação

No Access, os índices podem ser criados em um ou vários campos de uma tabela, conhecidos como chave composta.

O SQL Server lida com a indexação praticamente da mesma maneira. As tabelas indexadas são, na verdade, classificadas no disco rígido e armazenadas na ordem classificada. Esse processo é chamado de agrupamento. Agrupamento refere-se à classificação e ao armazenamento de dados do SQL Server no disco rígido com base no índice agrupado. Se um campo for indexado e não for agrupado, o SQL Server terá primeiro que consultar o índice para localizar os dados, o que poderá reduzir o desempenho.

Por exemplo, uma tabela de funcionários poderia ter um identificador exclusivo chamado EmployeeID. No entanto, essa tabela é quase sempre pesquisada com base no campo FirstName. O acesso aos dados da coluna FirstName é otimizado pela definição de um índice no campo EmployeeID e pela definição de sua propriedade clustered como true (como mostra a Figura 16). Como está agrupada, ela é armazenada fisicamente no disco rígido na ordem classificada, o que torna o acesso aos dados mais eficiente.

Figura 16. Definição de um índice na tabela para usar o agrupamento no SQL Server e obter benefícios no desempenho

Consultas do Access versus modos de exibição do SQL Server

Os modos de exibição do SQL Server são semelhantes às consultas do Access, como mostram as Figuras 17 e 18. Eles permitem especificar um conjunto de dados filtrados, possivelmente agrupados a partir de várias tabelas e de outros modos de exibição.

Os modos de exibição são úteis quando se lida com questões relacionadas à segurança. Por exemplo, para que um grupo de usuários possa exibir informações sobre um pedido de produto, mas não os detalhes do cartão de crédito vinculados ao pagamento, você:

Criará um modo de exibição que recupere apenas os campos não sigilosos da tabela de pedidos.
Recusará ao grupo de usuários qualquer acesso à tabela de pedidos.
Concederá ao grupo de usuários acesso à exibição.

Figura 17. Consultas no Access

Figura 18. Modos de exibição no SQL Server

Os modos de exibição, ao contrário das consultas, também podem aproveitar a indexação, o que pode melhorar significativamente o desempenho de um aplicativo, já que as consultas executam determinadas associações ou agregações com freqüência. Um modo de exibição indexado permite a criação de índices em modos de exibição cujo conjunto de resultados é armazenado e indexado no banco de dados.

Consultas do Access versus procedimentos armazenados do SQL Server

O SQL Server usa procedimentos armazenados para consultar os dados e fazer cálculos com eles. A principal vantagem dos procedimentos armazenados é que eles são compilados a primeira vez em que são executados. Isso significa que o SQL Server encontrará a melhor maneira de executar o procedimento armazenado e armazenará esse plano de execução na memória. A subseqüente execução do procedimento armazenado será mais rápida, pois o SQL Server já encontrou a melhor forma de executar a consulta.

Os procedimentos armazenados são criados e modificados no SQL Server Enterprise Manager, assim como as consultas do Access são editadas no Access (consulte a Figura 19). Os procedimentos armazenados são semelhantes às consultas do Access no que diz respeito a aceitarem parâmetros de entrada.

Figura 19. Procedimentos armazenados para consultar os dados e fazer cálculos com eles

Como os procedimentos armazenados são criados em T-SQL, eles oferecem uma vantagem em relação às consultas do Access, pois a lógica condicional e os cálculos podem ser usados para modificar ou retornar dados, bem como para executar algumas outras funções, como mostra a Figura 20.

Figura 20. Usando T-SQL para executar lógica condicional e cálculos em consultas

Com o SQL Server, você também pode depurar os procedimentos armazenados, o que é útil ao trabalhar com procedimentos armazenados que contenham lógica comercial complexa. O depurador oferece suporte à definição de pontos de interrupção, estabelecendo expressões de inspeção de variáveis e criando procedimentos passo-a-passo, como mostra a Figura 21.

Figura 21. Depuração avançada de consulta no SQL Server

Consultas do Access versus funções definidas pelo usuário do SQL Server

Juntamente com as funções internas do SQL Server, você também pode especificar blocos personalizados de instruções T-SQL. Esses blocos são conhecidos como UDFs (funções definidas pelo usuário). Implementadas praticamente da mesma maneira que as funções nas linguagens de programação, as UDFs são uma ferramenta poderosa que permite a reutilização de código e o encapsulamento da lógica comercial. Elas podem retornar um único valor (escalar) ou uma tabela.

UDFs escalares

Por exemplo, você poderia criar uma UDF para aceitar um valor em dinheiro, executar cálculos de impostos e retornar o preço incluindo o imposto. Essa função poderia, então, ser chamada em qualquer procedimento armazenado que exigisse um cálculo de imposto.

UDFs de tabela

O SQL Server 2000 introduziu um tipo de dados table, o qual pode retornar uma tabela de dados de uma função. Usar os tipos de dados table nas UDFs é muito mais eficiente do que criar e excluir tabelas físicas para executar consultas nos subconjuntos de dados. Eles são armazenados e manipulados na memória e não exigem nenhum acesso ao disco.

Para obter mais informações sobre funções definidas pelo usuário, consulte User-Defined Functions (em inglês).

Disparadores em tabelas e modos de exibição

O SQL Server incluiu suporte para disparadores. Disparadores são procedimentos armazenados executados quando os dados são atualizados, excluídos ou inseridos em uma tabela. Os disparadores podem ser definidos para executar quando uma linha ou um campo específico for atualizado. Lembre-se de que os disparadores podem ser usados para impor integridade referencial da mesma forma que as restrições. No entanto, as restrições são mais eficientes do que os disparadores e devem ser usadas sempre que possível.

Os disparadores podem ser usados para executar ações personalizadas quando houver alteração nos dados de uma tabela. Por exemplo, você poderia configurar um disparador para comparar os dados inseridos ou atualizados com os dados de outro campo de outra tabela, e atualizá-los de forma apropriada ou exibir uma mensagem de erro personalizada. Para obter mais informações sobre como usar disparadores para impor lógicas comerciais, consulte Enforcing Business Rules with Triggers (em inglês).

Os disparadores podem ser criados através do SQL Server Enterprise Manager e em um projeto de banco de dados do Visual Studio .NET, como mostra a Figura 22.

Figura 22. Disparadores criados em um projeto de banco de dados do Visual Studio .NET

Inicio da pagina

Escalabilidade e desempenho

O SQL Server oferece aprimoramentos significativos em relação ao Access no que diz respeito ao dimensionamento da solução de banco de dados para atender ao aumento de demanda dos negócios. Além disso, a arquitetura cliente/servidor aprimorada distribui a carga do processamento e resulta em melhor desempenho.

Suporte para mais usuários simultâneos

O Access oferece suporte a, no máximo, 255 usuários simultâneos e, por isso, não é uma solução viável de armazenamento de dados de nível corporativo. Em um ambiente de produção, é comum ter problemas graves de desempenho, bem como danos aos dados, quando 20 usuários tentam usar o banco de dados do Access simultaneamente em uma rede.

O SQL Server oferece suporte a uma base de usuários simultâneos limitada apenas pela memória disponível no sistema e, graças ao seu mecanismo otimizado de processamento de consultas e à sua capacidade de usar simultaneamente vários computadores, processadores e discos rígidos, ele pode ser dimensionado para atender a quaisquer exigências corporativas.

Suporte a um banco de dados maior

O Access oferece suporte a um banco de dados de, no máximo, 2 GB, incluindo tabelas vinculadas. Embora o uso de tabelas vinculadas teoricamente permita armazenar muito mais dados, é comum ter problemas de desempenho e na rede devido à quantidade de dados em processamento. Para obter mais informações, consulte a seção >Implementação do mecanismo, neste documento.

O SQL Server melhorou bastante os recursos de armazenamento, permitindo o armazenamento eficiente de 1.048.516 terabytes de dados em vários dispositivos.

Os arquivos de log mantêm um registro de toda a atividade do banco de dados

O SQL Server tem uma vantagem em relação ao Access: todas as transações (atualizações, inserções e exclusões no banco de dados) são armazenadas em um arquivo de log. Esse log registra as alterações nos dados e informações suficientes para posteriormente desfazer as modificações efetuadas durante cada transação, se necessário.

Ferramentas como o Lumigent Log Explorer permitem que você analise um log de transações do SQL Server e desfaça manualmente as transações (consulte a Figura 23). Para obter mais informações, consulte o site da Lumigent.

Figura 23. O Lumigent Log Explorer oferece controle total sobre o banco de dados do SQL Server, pois possibilita a análise de todas as transações anteriores.

Arquivos de banco de dados e de log divididos entre vários dispositivos

Os bancos de dados do Access são armazenados como arquivos .mdb únicos. Por isso, eles podem ser armazenados e executados em apenas uma máquina. Isso pode causar problemas quando o banco de dados e a base de usuários aumentam, pois o poder de processamento e o espaço de armazenamento ficam restritos ao hardware do único servidor do banco de dados.

Os bancos de dados do SQL Server são um grupo de arquivos físicos gerenciados pelo programa. Esses arquivos incluem, no mínimo, um arquivo de log de transações (com a extensão .ldf) e um arquivo de dados primário (com a extensão .mdf). Os bancos de dados do SQL Server também podem ter um ou mais arquivos de dados secundários (com a extensão .ndf). O arquivo de dados primário é usado como ponto de partida para o banco de dados e contém dados e referências aos arquivos de dados secundários.

Ao trabalhar com um banco de dados grande, armazenar o log de transações e vários arquivos de dados em computadores diferentes permite aproveitar o poder de processamento de vários computadores. Isso também permite que você use o espaço de armazenamento de vários computadores ou discos rígidos.

Consultas mais robustas

Os desenvolvedores do Access talvez tenham encontrado um erro de Memória Insuficiente ou Consulta Muito Complexa ao tentar executar uma consulta, um formulário ou um relatório baseado em uma consulta. Normalmente, isso ocorre porque a consulta que está tentando executar contém mais associações de tabela do que o Access pode processar. Para contornar esse problema, os desenvolvedores do Access normalmente são forçados a desperdiçar recursos na recriação de consultas e na reestruturação de tabelas.

O SQL Server foi reprojetado para oferecer suporte a consultas muito mais flexíveis. Em uma única consulta, você pode usar até:

256 tabelas na instrução SELECT;
Cerca de 256 KB de texto de consulta;
4.096 colunas na instrução SELECT.

Também é importante observar que o Access oferece suporte a até 50 subconsultas aninhadas, enquanto o SQL Server oferece suporte a apenas 32, no máximo.

Inicio da pagina

Trabalhando com dados

Criar consultas de dados no Access é diferente de criá-las no SQL Server. Há diferenças na linguagem da consulta e no designer de consulta. O SQL Server também oferece suporte a procedimentos armazenados, uma maneira eficiente de armazenar consultas de dados, bem como a funções definidas pelo usuário, as quais facilitam a reutilização da lógica comercial. Além disso, o SQL Server fornece um modelo de recuperação de falhas muito mais eficiente do que o modelo do Access.

Consultando dados

Otimização de consultas

Quando os dados são consultados remotamente no Access, todos são retornados ao cliente e qualquer filtragem e classificação é feita no cliente. Como os dados do SQL normalmente são consultados pela rede de um cliente, podem ocorrer grandes problemas de largura de banda da rede. Portanto, ao migrar seu back-end para o SQL Server, é importante recriar as consultas para que retornem apenas o conjunto solicitado de dados ao cliente (em vez de todo o conjunto de dados). Por exemplo, uma consulta com base em um formulário do Access seria:

SELECT * FROM Customers

A consulta anterior retornaria toda a tabela Customers quando o formulário fosse aberto. No SQL Server, essa consulta teria que ser otimizada para retornar apenas o registro atual. A consulta no SQL teria este formato:

SELECT * FROM Customers WHERE CustomerID = 'C00010'

Ela retornaria apenas uma linha/um registro. Cada vez que o usuário fosse para o registro anterior ou o próximo registro do formulário, CustomerID seria alterado e a consulta teria que ser novamente feita no banco de dados para recuperar o registro atual.

Esse método de filtragem no servidor ajuda a reduzir o tráfego da rede, pois executa a filtragem e a classificação no servidor do banco de dados e retorna apenas a quantidade mínima de dados solicitados.

Tipos de consulta

O Access fornece vários métodos de exibição de dados e criação de consultas. A Tabela 5 lista as opções possíveis ao migrar tipos de consulta internos do Access para o SQL Server.

Tabela 5. Opções de conversão de consultas do Access para o SQL Server

Tipo de consulta do Access	Opções de migração do SQL Server
Select	Uma instrução SELECT pode ser usada em um arquivo T-SQL, um procedimento armazenado ou um modo de exibição. As instruções SELECT também podem ser criadas usando o designer de consulta interno do SQL Server, o qual é semelhante ao designer de consulta do Access (consulte a Figura 24).
Crosstab	Uma instrução crosstab pode ser implementada como um arquivo T-SQL, um procedimento armazenado ou um modo de exibição. Tabelas temporárias podem ser usadas para consultar os conjuntos de dados necessários à tabela de referência cruzada na memória. As tabelas temporárias podem ser associadas e consultadas para recuperar os dados necessários da tabela de referência cruzada. Converter dados da tabela de referência cruzada do Access para que funcionem no SQL Server pode ser uma tarefa demorada. Você pode considerar a possibilidade de usar um aplicativo de terceiros para automatizar algumas das etapas. Uma solução flexível, eficiente e extensível para consultas de tabela de referência cruzada é o SQL Server Analysis Services. Com o Analysis Services, você pode criar cubos de dados OLAP (processamento analítico online) para permitir a geração de relatórios complexos e dinâmicos. Para obter uma explicação detalhada de como usar o SQL Server Analysis Services em seus dados, consulte Analysis Services (em inglês).
Make table	Uma instrução make table pode ser implementada como uma instrução T-SQL que usa a cláusula SELECT INTO para copiar dados de uma tabela para outra.
Update	Uma instrução update pode ser armazenada como uma instrução T-SQL ou um procedimento armazenado que usa a cláusula UPDATE.
Append	Uma instrução append pode ser armazenada como uma instrução T-SQL ou um procedimento armazenado que usa a cláusula INSERT INTO.
Delete	Uma instrução delete pode ser armazenada como uma instrução T-SQL ou um procedimento armazenado que usa a cláusula DELETE FROM.

Figura 24. Criar consultas SELECT, semelhante no Access e no SQL Server

Recursos da linguagem de consulta

A Tabela 6 resume as principais diferenças nos recursos de linguagem de consulta aos quais o Access e o SQL Server oferecem suporte (extraída do Access 2002 Desktop Developer's Handbook de Paul Litwin, et alii, SYBEX Inc., 2001).

Tabela 6. Diferenças entre as consultas de dados do Access e do SQL Server

Recurso	Com suporte no Access SQL com as Extensões Jet 4 SQL-92	Com suporte no SQL Server 2000 T-SQL
Segurança (GRANT, REVOKE, etc.)	Sim	Sim
Suporte à transação (COMMIT, ROLLBACK, etc.)	Sim	Sim
Modos de exibição (CREATE VIEW)	Sim	Sim
Tabelas temporárias	Não	Sim
Associações na cláusula FROM	Sim	Sim
Associações nas instruções UPDATE e DELETE	Sim	Não
Suporte para FULL OUTER JOIN e UNION JOIN	Não	Sim
Suporte para subconsultas na cláusula SET das instruções UPDATE	Não	Sim
Suporte para várias tabelas nas instruções DELETE	Sim	Não
SELECT DISTINCTROW	Sim	Não
SELECT TOP	Sim	Não
Cursores (DECLARE CURSOR, FETCH, etc.)	Não	Sim
Suporte a domínio (CREATE DOMAIN, ALTER DOMAIN, etc.)	Não	Sim
Suporte a restrições de verificação	Sim	Sim
Declarações (CREATE ASSERTION, DROP ASSERTION, etc.)	Não	Não
Construtores de valor de linha	Não	Não
Expressões CASE	Não	Sim
Suporte completo para integridade referencial na instrução CREATE TABLE	Não	Sim
Tabelas e códigos de erro padronizados do sistema	Não	Não
Tabelas e códigos de erro padronizados do sistema	Não	Não
Tipos de dados padrão	Sim	Sim
Operadores padrão de seqüência de caracteres	Não	Sim
Caracteres curinga padrão	Sim	Sim
Suporte a funções do VBA	Sim	Não
Suporte a funções do VBA	Sim	Não
Funções agregadas adicionais	Sim	Não
Instrução TRANSFORM	Sim	Não
Parâmetros em consultas ou procedimentos armazenados	Sim	Sim
Instrução SELECT INTO	Sim	Sim

Para obter mais informações sobre como criar consultas do Access no SQL Server, consulte Migrating Your Access Database to Microsoft SQL Server 7.0 (em inglês). (Observação: este artigo foi escrito para o SQL Server 7.0 e não foi atualizado.)

Capacidade para gerar scripts de objetos

SQL (Structured Query Language) é a linguagem padrão usada pelo Access e pelo SQL Server para acesso e manipulação de dados. A revisão mais recente da linguagem SQL é chamada de SQL-92, cujo nome inclui o ano em que foi concluída. A Microsoft adicionou algumas de suas próprias extensões à linguagem SQL base, as quais variam entre as duas soluções de DBMS.

O Access oferece suporte às extensões SQL-92 e Jet 4 ANSI-92, as quais incluem suporte para gerenciamento de transações usando o SQL.

As extensões Jet 4 ANSI-92 também adicionam suporte para facilitar o gerenciamento da segurança do banco de dados. No entanto, não há suporte para alguns recursos, como a definição e alteração de propriedade do objeto de banco de dados.

No SQL Server 2000, a Microsoft adicionou extensões personalizadas à linguagem SQL-92 base. Essas extensões adicionam suporte a scripts para alguns recursos importantes, como:

Procedimentos armazenados.
Transações distribuídas.
Funções do sistema operacional.
Subconsultas mais flexíveis.
Aliases em consultas.
Backup e restauração de dados.

A linguagem T-SQL é uma poderosa extensão ao conjunto padrão de comandos SQL. Ela fornece toda a funcionalidade necessária para:

Recuperar, modificar, excluir e adicionar dados às tabelas de banco de dados.
Aceitar e retornar parâmetros.
Executar cálculos.
Executar funções internas e definidas pelo usuário.
Copiar dados entre servidores.

O T-SQL é como um cruzamento entre as consultas do Access e o VBA, pois as consultas de dados podem ser combinadas com lógica condicional e cálculos.

Lembre-se de que o SQL Server oferece suporte total ao padrão SQL-92; portanto, o uso de extensões não é necessário.

Variáveis de tabela: úteis em consultas complexas

Para fazer cálculos no Access em um conjunto de tabelas associadas, você cria uma consulta definindo as associações. Em um aplicativo que usa esses dados, cada vez que a consulta é usada em uma instrução SELECT do SQL, todas as tabelas precisam ser associadas novamente, uma operação que pode consumir muitos recursos (especialmente em um ambiente de vários usuários).

Por exemplo, para excluir todos os clientes cujo nome comece com a letra "A" e todos os pedidos de cliente e históricos dos pedidos, no Access você:

Criaria uma consulta SELECT para obter todos os códigos de cliente necessários:
```
SELECT Customers.CustomerID
FROM Customers
WHERE Customer.FirstName LIKE 'A%'
```

Incluiria a consulta SELECT em três consultas DELETE para excluir todos os clientes, pedidos e históricos dos pedidos necessários:

DELETE FROM Orders
WHERE Orders.CustomerID IN 
(
SELECT Customers.CustomerID
FROM Customers
WHERE Customer.FirstName LIKE 'A%'
)
And
DELETE FROM OrderHistory
WHERE OrderHistory.CustomerID IN 
(
SELECT Customers.CustomerID
FROM Customers
WHERE Customer.FirstName LIKE 'A%'
)

And
DELETE FROM Customers
WHERE Customer.FirstName LIKE 'A%'

Essa é uma maneira ineficiente de executar essa operação, pois um filtro LIKE, que consome muitos recursos, teria que ser executado na tabela Customers para cada operação de exclusão. Executar esses filtros WHERE com caracteres curinga criaria grandes problemas de desempenho, pois a tabela Customers ficaria com milhões de registros.

Uma maneira mais eficiente de executar essa operação é usar variáveis de tabela, um recurso disponível no SQL Server. As variáveis de tabela são usadas como tabelas comuns na sintaxe de SQL. No entanto, elas diferem das tabelas comuns, pois são armazenadas temporariamente na memória e não no disco rígido. Como o acesso à memória é significativamente mais rápido do que o acesso ao disco rígido, as variáveis de tabela tornam-se úteis na execução de várias operações no mesmo conjunto de dados filtrados ou associados.

Para implementar o exemplo anterior usando uma variável de tabela, você:

Declararia a tabela:

DECLARE @tmpCustomerIDs TABLE (CustomerID nvarchar(50))

Obteria o conjunto de registros filtrados e os armazenaria na variável de tabela:

INSERT INTO @tmpCustomerIDs (CustomerID)
(SELECT CustomerID FROM Customers WHERE Customers.ContactName LIKE 'A%')

Executaria todas as operações relacionadas a clientes, pedidos e históricos de pedidos usando valores da variável de tabela:

DELETE FROM Orders
WHERE Orders.CustomerID IN 
(
SELECT CustomerID
FROM @tmpCustomerIDs
)
And
DELETE FROM OrderHistory
WHERE OrderHistory.CustomerID IN 
(
SELECT CustomerID
FROM @tmpCustomerIDs
)
And
DELETE FROM Customers
WHERE Customers.CustomerID IN
(
SELECT CustomerID
FROM @tmpCustomerIDs
)

As tabelas temporárias são outro mecanismo oferecido pelo SQL Server para executar operações em um conjunto dinâmico de dados de forma eficiente. Ao contrário das variáveis de tabela, elas permanecem na memória por mais tempo e, portanto, podem exigir mais bloqueios de dados e recursos de registro em log.

Recuperando-se da falha no sistema

A maioria dos desenvolvedores já encontrou um erro de Formato de banco de dados não reconhecido ao tentar abrir um banco de dados corrompido (como mostra a Figura 25). Quando ocorre uma falha do sistema (como uma falha do sistema operacional ou queda de energia), as suas opções são:

Tentar recuperar os dados do arquivo .mdb corrompido usando a ferramenta de compactação e reparo do Access e, em seguida, importar os dados recuperados para um banco de dados em branco a fim de reduzir o número de registros corrompidos. Esse não é um processo à prova de falhas e há a possibilidade de perda de dados.
Restaurar de um backup recente, o que resultaria no desperdício de recursos para inserir os dados perdidos novamente.
Executar a ferramenta de compactação Jet, Jetcomp.exe. Normalmente, é mais eficiente do que executar a ferramenta de compactação e reparo. No entanto, ainda não há garantia de que todos os dados não estarão corrompidos.
Enviar o banco de dados corrompido para um especialista em recuperação de bancos de dados, que usará métodos proprietários exclusivos para extrair dados do banco de dados. Esse é um processo provavelmente caro e pode ter implicações de segurança, pois terceiros manusearão seus dados.

Figura 25. Erro ao tentar abrir um banco de dados corrompido do Access

O SQL Server oferece um controle muito maior sobre a recuperação de dados. Você pode selecionar um dos três modelos de recuperação em cada banco de dados do SQL Server para determinar como foi feito o backup dos dados e qual é a sua exposição à perda de dados. Os três modelos de recuperação são:

Recuperação Simples. Permite a recuperação do backup mais recente.
Recuperação Completa. Permite a recuperação do banco de dados ao ponto de falha. Esse modelo exige uma quantidade maior de recursos do sistema e de espaço em disco (para o registro em log).
Recuperação com Registro Mínimo de Transação em Massa (bulk-logged). Permite a recuperação do banco de dados ao ponto do último backup registrado em log. Isso exige uma quantidade menor de recursos do sistema e de espaço em disco do que o modelo Recuperação Completa, embora haja uma chance maior de você precisar inserir os dados manualmente.
Esses modelos de recuperação fornecem flexibilidade para escolher a melhor maneira de recuperar-se de falhas no sistema, bem como disponibilidade e recursos do sistema.

Dica: a principal vantagem dos backups de dados do SQL Server em relação aos backups do Access é que eles podem ser feitos com o banco de dados em funcionamento. Os usuários não precisam fazer logoff. Isso aumenta a disponibilidade do banco de dados para os usuários e permite um tempo de atividade muito maior.

Comparando bancos de dados

No Access, manter o banco de dados de produção ativo e atualizado com as últimas alterações estruturais é um projeto contínuo. O banco de dados precisa ser colocado offline rapidamente para fazer alterações estruturais e converter dados, mas isso pode ser difícil quando as pessoas contam com o sistema. A conversão de dados também pode levar tempo, pois novos campos e relacionamentos talvez tenham sido adicionados.

Para fazer alterações estruturais em um banco de dados do Access, normalmente ocorre o seguinte:

Os desenvolvedores trabalham no banco de dados do aplicativo e fazem as alterações estruturais no banco de dados que contém os dados.
As alterações no banco de dados que contém os dados são rastreadas e o código Update Queries, DAO ou ADO é criado para fazer a atualização.
Após a conclusão do desenvolvimento, os bancos de dados precisam ser colocados offline para que as atualizações sejam feitas manualmente.

Aplicativos de terceiros, como o SSW Data Renovator, ajudam a reduzir a indisponibilidade do sistema e a probabilidade de erros, pois automatizam parte desse processo. O SSW Data Renovator compara o novo banco de dados com o banco de dados de produção, gera relatórios sobre todas as diferenças entre os dois e fornece uma interface em estilo de assistente para mover automaticamente os dados para a nova estrutura.

Embora o SQL Server tenha o benefício de não exigir que o banco de dados seja colocado offline para atualizações estruturais, os administradores do banco de dados ainda precisam:

Analisar todos os esquemas do banco de dados e logs de quorum em busca de alterações estruturais.
Criar manualmente scripts de migração para enviar ao banco de dados de destino.

Utilitários de terceiros, como o Red-Gate SQL Compare ou o SSW SQL Deploy ajudam a automatizar essa tarefa, pois:

Comparam todos os objetos em ambos os bancos de dados, incluindo procedimentos armazenados, relacionamentos, tabelas, modos de exibição e funções definidas pelo usuário.
Relatam todas as diferenças.
Geram scripts de migração que podem ser executados diretamente no banco de dados de destino.

Inicio da pagina

Conclusão

O Microsoft SQL Server 2000 é uma solução de banco de dados de nível corporativo com recursos amplamente aprimorados de escalabilidade, manutenção e recuperação de bancos de dados em comparação com o Microsoft Access 2002. Por ter como base a arquitetura cliente/servidor, o SQL Server é bem diferente do Access na forma como processa e envia dados por uma conexão remota. O SQL Server também oferece muitos recursos para facilitar e tornar mais flexível a tarefa de consulta de dados, reutilização de lógica comercial e backup de dados.

Inicio da pagina

Glossário

ADO.NET
Um modelo de acesso a dados fornecido com o Microsoft .NET Framework. Ele foi criado especificamente para a Web, considerando escalabilidade, ausência de estado e XML.

Arquitetura cliente/servidor
Uma arquitetura de software que promove escalabilidade permitindo que vários clientes façam solicitações e recebam resultados de um servidor central ou grupo de servidores. A carga de processamento é compartilhada entre o cliente e o servidor.

Agrupamento
Um método de indexação e classificação de dados diretamente no disco rígido para permitir uma consulta de dados extremamente rápida.

Data Transformation Services
Uma ferramenta fornecida com o SQL Server que permite importar dados de/exportar dados para várias fontes de dados que usam uma arquitetura baseada em banco de dados OLE, como o Microsoft Excel.

OLAP
Processamento analítico online. Um modelo de armazenamento de dados para ajudá-lo a analisar dados comerciais de diferentes pontos de vista. Por exemplo, você pode usar o OLAP para exibir todos os produtos vendidos em uma determinada região, acima de um preço específico e em um determinado período de tempo.

SQL Server Enterprise Manager
Uma ferramenta fornecida com o SQL Server para facilitar o gerenciamento de objetos, usuários, backups e permissões do banco de dados.

SQL Server Profiler
Uma ferramenta fornecida com o SQL Server para ajudá-lo a otimizar consultas pela identificação de transações do banco de dados especialmente lentas ou que consumam muitos recursos.

SQL Server Query Analyzer
Uma ferramenta fornecida com o SQL Server para permitir a criação e a depuração de consultas do banco de dados.

T-SQL
Transact-SQL. Uma extensão do padrão de linguagem de consulta SQL-92 que fornece mais recursos ao SQL Server, como procedimentos armazenados, backup e restauração de dados, bem como transações distribuídas.

UDDT
Tipos de dados definidos pelo usuário. Um recurso do SQL Server que permite criar seus próprios tipos de dados com base nos tipos de dados base já existentes no programa. Os UDDTs aplicam lógicas comerciais mais rígidas aos dados.

UDFs
Funções definidas pelo usuário. Blocos personalizados de instruções T-SQL que facilitam a reutilização da lógica comercial por todo o aplicativo de banco de dados.

Visual Studio .NET
Um IDE (ambiente de desenvolvimento integrado) para que os desenvolvedores possam criar visualmente vários aplicativos conectados ao Microsoft .NET. Ele fornece ferramentas eficientes de criação, desenvolvimento, teste e implantação de aplicativos da Web e do Windows habilitados para .NET.

XML
Extensible Markup Language. Uma maneira padrão amplamente usada de representar texto e dados em um formato que possa ser processado sem muita ação humana ou de máquina.

Para obter mais informações

Página de produtos do Microsoft SQL Server

Sobre o autor

Adam Cogan é Diretor de arquitetura da SSW, um Microsoft Certified Partner especializado em soluções baseadas no Office e no .NET. Na SSW, Adam desenvolve soluções personalizadas para empresas de vários setores usando tecnologias da Microsoft, como SQL Server 2000, .NET e Office 2003. Adam também é responsável pelo Grupo de Usuários do Microsoft .NET em Sydney e está ativamente envolvido no processo regional de gerenciamento da INETA.

Inicio da pagina