Blog da Kurole Web Design

Criando as tabelas de usuários e incluindo informações
CODE
create table `usuario` (
idusuario integer unsigned not null auto_increment,
nome varchar(30),
primary key (idusuario)
) engine=InnoDb;

insert into `usuario`
(nome) values
(“Paulo”),
(“Joao”),
(“Maria”);

create table `noticias` (
idnoticia integer unsigned not null auto_increment,
idusuario integer unsigned default 0,
noticia varchar(50) not null default ”,
datahora timestamp,
primary key (idnoticia)
) engine=InnoDb;

Incluindo algumas notícias…
CODE
insert into `noticias`
(idusuario, noticia, datahora)
values
(1, “Morreu o gato da vovó”, “2009/08/01 10:15:20”),
(1, “O ônibus atrasou hoje”, “2009/08/02 12:25:20”),
(1, “Vovó chora no enterro do gatinho”, “2009/08/03 10:35:00”),
(2, “Preço do Trigo abaixa 5%”, “2009/08/01 10:00:00”),
(2, “Aumenta o Consumo de Carne”, “2009/08/06 18:15:00”),
(3, “Encontrada a cura para a gripe A”, “2009/07/31 18:00:00”),
(3, “Procura-se Susan desesperadamente”, “2009/08/04 10:00:00”);

Selecionando a notícia mais recente de cada usuário. Isso, depois,
será uma subquery.

CODE
select max(datahora), idusuario
from `noticias`
group by idusuario

Agora que sei qual é a notícia mais recente de cada usuário,
ligo as notícias e usuários com essa subquery…
Aí vai um exemplo:

CODE
select a.idusuario, a.noticia, a.datahora
from `noticias` as a
inner join
(select max(datahora) as datahora, idusuario
from `noticias`
group by idusuario
) as b
on (a.idusuario=b.idusuario and a.datahora=b.datahora)

Maneiras Corretas de Ordernação!

No Mysql
select * from tabela order by rand()

No SQL SERVER
select * from tabela order by newid()

No PostGreSQL
Select * from tabela order by random()

No Oracle
Select coluna from (select coluna from tabela order by dbms_random.value) where rownum = 1

Em MySQL a sintaxe é:
SELECT campo1, campo2 FROM tabela ORDER BY campo1 LIMIT 50,100

Em Firebase/Interbase a sintaxe é:
SELECT campo1, campo2 FROM tabela ORDER BY campo1 ROWS 50 TO 100

Em MS SQL Server a sintaxe é:
SELECT * FROM (SELECT campo1, ROWNUM qtd_linhas FROM table) WHERE qtd_linhas BETWEEN 50 AND 100;

Em PostgreSQL a sintaxe é:
SELECT campo1, campo2 FROM tabela ORDER BY campo1 LIMIT 50 OFFSET 50

Em ORACLE 8i a sintaxe é:
SELECT * FROM (SELECT * FROM tabela) WHERE ROWNUM >= 50 AND ROWNUM <= 100

Olá pessoal! Neste artigo veremos a última parte da criação de uma replicação entre o SQL Server e o MySQL: a verificação da replicação.

• Passo 8: Verificando a replicação

Após a execução com sucesso do passo 7, que descreve com detalhes a criação do assinante para a publicação, a replicação já está operacional, ou seja, os dados já estão sendo replicados do SQL Server. Para confirmar a replicação, basta executar o comando SHOW TABLES dentro do MySQL e verificar que a tabela MSrepl7, uma tabela auxiliar à replicação, e a tabela TB_MSSQL_MYSQL foram criadas corretamente. Além de verificar a criação das tabelas, podemos enviar uma instrução SELECT para verificar os dados. A Figura 8.1 mostra esta verificação por meio do acesso remoto no Putty, que é um cliente Windows para o SSH instalado no Linux.

Figura 8.1 Verificando as tabelas criadas pela replicação.

Devemos lembrar que a replicação criada é do tipo Transacional e que, neste modo, o MySQL deve apenas receber os dados e não modificá-los. Deste modo, toda a modificação nos dados realizada no SQL Server será replicada em poucos instantes para o MySQL. Para provar esta afirmação, vamos realizar um INSERT, um DELETE e um UPDATE na tabela TB_MSSQL_MYSQL do SQL Server, como a Figura 8.2 mostra.

Figura 8.2. Modificando os dados da tabela TM_MSSQL_MYSQL.

Após executar as três instruções devemos aguardas alguns segundos para verificar se estas modificações já foram replicadas para o MySQL. É importante lembrar que a replicação transacional vai replicar APENAS as três instruções, economizando a banda da rede. A primeira instrução executada no SQL Server faz a inserção de uma nova linha na tabela TB_MSSQL_MYSQL, com os valores 4 para a coluna ID e o caracter D para a coluna NAME. A segunda instrução apaga a primeira linha da tabela, cunho valor da coluna ID é 1. A terceira instrução coloca o caractere A para a coluna NAME na linha em que a coluna ID for igual a 2. Verificando o conteúdo da tabela TB_MSSQL_MYSQL no MySQL por meio de uma instrução SELECT, mostrado na Figura 8.3, podemos verificar que a replicação está funcionado corretamente.

Figura 8.3. Verificando a replicação dos dados no MySQL.

Com isso terminamos de criar a replicação do SQL Server para o MySQL como ela foi especificada. Com este tipo de replicação o MySQL pode ser utilizado como um servidor de backup dos dados, ou até mesmo como uma alternativa de acesso quando o SQL Server não estiver disponível.

Como comentário final gostaria de deixar claro que não devemos pensar em tecnologias de bancos de dados diferentes como inimigas. Esta seqüência de artigos mostrou que não é preciso enxergar o SQL Server vs. MySQL, mas sim enxergar que estas tecnologias podem trabalhar bem em conjunto. Ao invés de encarar diferentes bancos de dados como inimigos, do tipo SQL Server x MySQL, podemos imaginar SQL Server + MySQL, onde os dois bancos de dados colaboram para atender as nossas necessidades.

Um grande abraço e até a próxima pessoal

Olá pessoal. Dando continuidade à seqüência de artigos que ensinam como montar uma replicação do SQL Server para o MySQL, veremos nesta quinta parte como criar a assinatura para a publicação criada na sexta parte.

• Passo 07: Assinando a publicação

Após a criação da publicação, descrita em detalhes no passo 6, devemos criar uma assinatura para esta publicação. O processo de criação de uma assinatura (subcription) geralmente é executado nos assinantes (subscribers), pois devem ser deles a iniciativa de receber os dados. Contudo, na publicação entre o SQL Server e o MySQL, e em todo tipo de replicação que envolve fontes de dados que não sejam o SQL Server, devemos configurar a assinatura diretamente no servidor de publicação.

Para iniciar a criação da assinatura devemos utilizar a janela Create and Manage Publications on PICHILIANI, que é mesma janela utilizada para a criação da publicação. Como descrito no passo 6, para acessar esta janela devemos acionado a opção Wizards… partir do Menu Tools do Enterprise Manager. Na janela de assistentes disponíveis devemos expandir o tópico Replication e escolher a opção Create Publication Wizard e clicar no botão OK. Porém, desta vez já existe a publicação chamada From SQL Server to MySQL, que aparece quando expandimos o nome do servidor. Devemos selecionar a publicação e clicar no botão Push new subscription…, como a Figura 7.1 mostra.

Figura 7.1. Selecionando a publicação From SQL Server to MySQL.

A próxima tela do assistente apresenta a janela de boas vidas, que podemos pular apertando o botão Avançar >. Em seguida, o assistente pergunta qual será o assinante que deseja assinar a publicação. Para que o nome do servidor MySQL, identificado pelo DSN TesteMySQL parece na lista de possíveis servidores devemos seguir corretamente todas as etapas descritas no passo 5, onde habilitamos esta fonte de dados para participar em alguma replicação como assinante. Caso todas as etapas do passo 5 tenha sido seguidas corretamente e mesmo assim a fonte de dados não aparecer nesta segunda janela do assistente de criação de assinatura, basta fechar e abrir novamente o Enterprise Manager.

Nesta segunda tela do assistente devemos selecionar a fonte de dados TesteMySQL (MySQL ODBC 3.51 Driver), que deve estar dentro do item Enabled Subscribers, e clicar no botão Avançar >, como a Figura 7.2 mostra.

Figura 7.2. Selecionando o assinante da publicação.

A próxima tela do assistente pergunta qual é o nome do banco de dados, do assinante, que vai receber os dados da replicação. No nosso exemplo o nome do banco de dados é MSSQL_MYSQL, que foi criado no MySQL no passo 3. Basta digitar MSSQL_MYSQL no campo Subscription database name e clicar no botão Avançar >, como mostra a Figura 7.3, para seguirmos adiante no assistente.

Figura 7.3. Especificando o nome do banco de dados do assinante.

Na próxima tela do assistente devemos configurar a freqüência em que os dados da nossa publicação serão enviados para esta assinatura. Para suportar ambientes onde não há conectividade constante entre o Publicador/Distribuidor o SQL Server permite a criação de um horário pré-determinando e recorrente para o envio de dados da publicação. Nestes casos o SQL Server cria um agendamento específico para o job que envia os dados da replicação para os assinantes.

Como a especificação da replicação que estamos montando diz que os dados devem ser replicados o mais cedo possível, devemos escolher a primeira opção deta tela, Continuously – provides minimal latency between when an action occours at the Publishers and is propagated to the Subscriber, o que indica que a replicação será contínua e a latência será mínima. É importante lembrar que esta opção requer uma conexão constante entre o Publicador/Distribuidor e os assinantes e que esta configuração de latência é específica da assinatura e não da publicação. A Figura 7.4 mostra a opção da opção de menor latência para a assinatura que estamos criando.

Figura 7.4. Configurando a latência da assinatura.

A penúltima tela do assistente de criação de publicação pergunta a respeito do que fazer no início da replicação. Como estamos utilizando uma replicação do tipo Transacional, podemos escolher se desejamos criar a estrutura das tabelas/view do artigo ou não. Como no nosso exemplo criamos apenas o banco de dados no MySQL, devemos marcar a opção Yes, initialize the schema and data e também a opção Star the Snapshot Agent to begin the initialization process imediately. Com estas duas opções marcadas, como na Figura 7.5, ao término do assistente de criação da assinatura a estrutura da tabela TB_MSSQL_MYSQL será criada no MySQL e os dados já começaram a ser enviados continuamente.

Figura 7.5. Configurando a inicialização do schema e dos dados.

Por fim o assistente de criação da assinatura mostra o status do serviço SQLServerAgent, responsável pela execução de jobs no SQL Server. Como todo o processo de replicação do SQL Server envolve jobs, é necessário manter o serviço SQLServerAgente ativado tanto no Publicador como no Distribuidor. No nosso exemplo, o servidor PICHILIANI assume os papeis de Publicador e o Distribuidor e por isso deve manter o serviço SQLServerAgent ativado. A Figura 7.6 apresenta a tela de confirmação de ativação deste serviço.

Figura 7.6. Janela de ativação do serviço SQLServerAgent.

A última tela do apenas apresenta um sumário do que foi configurado. Ao clicar no botão Finish todas as configurações da assinatura são realizadas e a publicação começa a todo vapor. A Figura 7.7 apresenta a janela de criação da assinatura após o término do assistente.

Figura 7.7. Término do assistente de criação da assinatura.

Com o término do passo 7 a assinatura da publicação está pronta e funcionando. O próximo e último passo envolve a verificação da replicação de dados por meio da execução de instruções no SQL Server e no MySQL.

Um grande abraço e até a próxima pessoal

Olá pessoal. Continuamos a falar sobre replicação do SQL Server para o MySQL, descrevendo os passos para criar uma publicação Transacional. É nesta parte que especificamos qual tabela do SQL Server será replicada, por meio da criação da publicação.

Passo 6: Criando a Publicação

Criar uma publicação no SQL Server envolve a configuração de qual banco de dados e tabelas serão utilizadas na publicação. É importante notar que podemos criar uma publicação APENAS se já tivermos configurado os servidores que agiram como Publicador e o Distribuidor. Neste nosso exemplo de replicação tanto o Publicador como o Distribuidor são a mesma máquina, chamada PICHILIANI.

Para iniciar a criação da publicação iremos utilizar o assistente de Publicação do SQL Server. Este assistente nos guiará durante todos os passos da publicação e deve ser acionado a partir do Menu Tools, opção Wizards… do Enterprise Manager. Na janela de assistentes disponíveis devemos expandir o tópico Replication e escolher a opção Create Publication Wizard e clicar no botão OK, como a Figura 6.1 mostra.

Figura 6.1. Escolha do assistente de criação de Publicação.

Após a escolha do assistente Create Publication Wizard o SQL Server apresenta uma tela muito útil para o gerenciamento de publicações. Esta tela, apresentada na Figura 6.2, mostra cada banco de dados do servidor. Quando se expande o banco de dados são mostradas as publicações relacionadas, tornando fácil o gerenciamento de diversas publicações. Para o nosso exemplo, basta selecionar o banco de dados REPL_MSSQL_MYSQL e clicar no botão Create Publication… Como esta tela, apresentada na Figura 6.2, é utilizada para gerenciar as publicações, também vamos utilizá-la para criar a assinatura futuramente. Outros botões permitem a realização de tarefas relacionadas às publicações, como a alteração de propriedades ou a geração de scripts da publicação.

Figura 6.2. Janela de criação e configuração de publicações.

Ao clicar no botão Create Publication…, com o banco de dados REPL_MSSQ_MYSQL selecionado, a janela de boas vindas do assistente para criação de uma nova publicação é apresentada. Como esta tela é apenas informativa, podemos clicar no botão Avançar > para chegarmos à tela apresentada na Figura 6.3. Nesta tela devemos apenas confirmar para qual banco de dados que será criada a publicação, que no exemplo chama-se REPL_MSSQ_MYSQL. Após confirmar o banco de dados, basta clicar em Avançar > para seguirmos com o assistente.

Figura 6.3. Janela de escolha do banco de dados que vai receber a Publicação.

A próxima tela apresenta os três tipos de replicação disponíveis, junto com uma pequena explicação. Uma pequena descrição de cada tipo é apresentada em seguida:

Replicação Snapshot: Este tipo de replicação envia toda a estrutura e os dados no momento da sincronização. Por sempre toda a estrutura e os dados este tipo de replicação geralmente é a que mais consome largura de banda e a que mais demora. É utilizada em ambientes onde os servidores que recebem os dados, os assinantes, fazem modificações nos dados que não devem ser encaminhadas e, por esta característica, a cada sincronia a base de dados deve ser completamente recriada pela replicação.

Replicação Transacional: Este é o tipo de replicação mais utilizado, pois inicialmente é feita uma sincronia da estrutura para recriar o ambiente nos assinantes. A cada novo sincronia apenas os dados que foram inseridos/modificados/excluídos do Publicador são replicados para o assinante, na forma de transações. Por replicar apenas a diferença entre dados, esta replicação é consome menos recursos e é mais fácil de gerenciar. No nosso exemplo utilizaremos este tipo de replicação. Notem que, por padrão, a replicação Transacional não permite que os assinantes modifiquem os dados, ou seja, a base de dados do assinante é somente para leitura. Porém existe como habilitar a modificação dos dados para o assinante, mas não a sua propagação para o Publicador.

Replicação Merge: A replicação Merge é o tipo de replicação onde tanto os Assinantes como os Publicadores podem modificar os dados e encaminha-los para qualquer direção. Este tipo de replicação pode resultado em conflitos nos dados, pois a modificação em um determinado dado por um Publicador e por um Assinante pode ser diferente, gerando um conflito. Em geral, este tipo de replicação é a que dá mais trabalho para gerenciar e que pode ser substituída pela criação de duas replicações do tipo Merge.

Aqui foi apresentada apenas uma explicação simples de replicação. Para mais informações recomendo fortemente a leitura do tópico de replicação no Books OnLine, a documentação eletrônica oficial da Microsoft.

Como citado anteriormente, a replicação que utilizaremos neste exemplo é do tipo Transacional, como mostrada na Figura 6.4.

Figura 6.4. Escolhendo a replicação Transacional.

A próxima janela do assistente permite a especificação do tipo de assinante que estará envolvido nesta replicação. Aqui é importante lembrar que estamos acessando o MySQL por meio de um driver ODBC e por isso devemos marcar apenas a opção Heterogeneous data sources, such as Oracle or Microsoft Access; or servers running earlier versions of SQL Server, como a Figura 6.5 mostra.

Figura 6.5. Especificando fontes de dados heterogêneas na replicação.

Na próxima etapa do assistente devemos definir um artigo, que nada mais é do que quais tabelas ou views estarão envolvidas na publicação. Um artigo pode conter várias tabelas e views, assim como uma tabela ou uma view pode estar em diferentes artigos. Para o nosso exemplo, só existe a tabela TB_MSSQL_MYSQL no banco de dados REPL_MSSQ_MYSQL e por isso devemos selecionar a opção Show do lado esquerdo da janela para mostrar a tabela TB_MSSQL_MYSQL no lado direito. Também devemos selecionar a tabela no lado esquerdo. Esta janela é apresentada na Figura 6.6, que também permite a escolha de opções avançadas da publicação quando se clica no botão Article Defaults.

Uma pequena nota: se a tabela que selecionarmos para a publicação não possuir uma chave primária ela não poderá ser incluída no artigo, ou seja, ela não poderá ser replicada. Esta é uma exigência da replicação do tipo Transacional e, como a tabela TB_MSSQL_MYSQL, criada no passo 2, contém uma chave primária na coluna ID podemos seguir adiante com o assistente.

Figura 6.6. Escolha de tabelas e views para o artigo da publicação.

Em seguida, o assistente de publicação pergunta qual será o nome desta publicação o e qual é a descrição dela. Para facilitar, coloquei o nome desta replicação como From SQL Server to MySQL, porém pode-se colocar um nome padronizado. Também aconselho a colocação de uma descrição que contenha alguns detalhes sobre a publicação, como a Figura 6.7 mostra.

Figura 6.7. Colocando o nome e a descrição da Publicação.

Já estamos quase no final da criação da Publicação. Porém falta definir ainda se a publicação vai conter algum filtro. Este filtro permite que apenas algumas linhas da tabela, filtradas por uma cláusula WHERE, sejam envolvidas na publicação. Também pode-se especificar quais colunas podem ser envolvidas na replicação.

Imagem a seguinte situação: uma tabela grande contendo várias colunas precisa ser replicação da matriz para várias filiais. Porém cada filial deve receber apenas os seus dados que lhe pertencem. Uma técnica para resolver este problema de filtro de dados é a criação de uma coluna na tabela indicando qual dado deve ser replicado para qual filial. Em segunda, especifica-se um filtro como uma cláusula WHERE na replicação.

Para o nosso exemplo não utilizaremos filtros e, devido a isso, a opção No, create the publication as specified deve ser marcada, como a Figura 6.8 mostra.

Figura 6.8. Indicando que a publicação não contém filtros.

Com isso terminamos o assistente de criação de publicação. Ao clicar no botão Finish da última tela o SQL Server automaticamente já começa a criação dos jobs e depois objetos de bancos de dados necessários para a publicação, passo que é mostrado na Figura 6.9. Quando o SQL Server terminar de criar os objetos somos automaticamente redirecionados para a janela apresentada na Figura 6.2, porém agora a Publicação que acabamos de ser criada está selecionada. Notem que nada foi replicado ainda, pois nenhum assinante resolver assinar a publicação ainda.

Figura 6.9. Criação dos objetos da publicação.

Com o término do passo 6 a publicação já está pronta para ser assinada. O próximo passo que veremos envolve a criação de uma assinatura para a publicação que foi criada no passo 6.

Um grande abraço e até a próxima pessoal

Olá pessoal. Neste artigo vamos dar continuidade à seqüência de passos necessários para montar a replicação de dados entre o SQL Server e o MySQL. Nesta etapa veremos como configurar o acesso do SQL Server ao MySQL, por meio do driver ODBC. Para mais informações sobre a especificação da replicação, aconselho aos leitores verem as partes anteriores desta série que explica como replicar dados entre o SQL Server e o MySQL.

Passo 4: Criando o DSN

Antes de começar a configuração do ODBC que permitirá o SQL Server acessar o MySQL, é necessário instalar o driver ODBC chamado MySQL-Conector/ODBC versão 3.51.12, que é livre e pode ser baixado a partir do link http://dev.mysql.com/downloads/connector/odbc/3.51.html.

Uma vez que este driver esteja instalado e configurado, estamos quase prontos para configurar o acesso. Mas antes é necessário tomar as devidas atitudes para garantir a conectividade entre o servidor que está executando o Windows, do SQL Server, e o servidor que está executando o Linux, do MySQL.

Em termos de rede, o servidor Windows foi configurado com o endereço I.P. 192.168.1.3 e o servidor Linux foi configurado com o endereço I.P. 192.168.1.5. Deve-se verificar que os dois servidores se enxergam normalmente, ou seja, que há conectividade entre eles. Fazer o famoso teste do ping é o suficiente para verificar esta conectividade. Em seguida, deve-se verificar se há algum firewall entre o servidor Windows e o Linux. O driver ODBC utiliza a porta padrão 3306 TCP para se conectar ao MySQL. Esta porta deve estar liberada em quaisquer firewall que exista entre o servidor Windows e o servidor Linux.

Também é necessário configurar o MySQL para que ele aceite conexões provenientes do servidor Windows. Para realizar esta configuração, é necessário se conectar ao Linux, como o passo 2 desta série de colunas mostrou, e executar a instrução GRANT da Listagem 4.1, que concede o acesso remoto ao servidor MySQL. Notem que é necessário trocar o valor <sua_senha> do comando apresentado na Listagem 4.1 pela senha do usuário root.

grant all on *.* to root@(192.168.1.3) identified by "(<sua_senha>";

Listagem 4.1 Comando que permite o acesso remoto ao MySQL.

A partir deste ponto já podemos configurar o driver ODBC no Windows para que ele acesse o MySQL. Com o driver já instalado, devemos acessar o ícone Fontes de Dados (ODBC), que se encontra dentro do Painel de Controle e do ícone Tarefas Administrativas. Em seguida, devemos clicar na aba Fontes de dados do usuário e escolher o botão Adicionar…, que apresentará a tela da Figura 4.1.

Figura 4.1 Escolha do driver ODBC.

Na janela apresentada, é necessário escolher a opção MySQL ODBC 3.51 Driver, que já está selecionada na Figura 4.1. Utilizando esta opção dizemos ao Windows que desejamos criar um novo DSN (Data Source Name) que utiliza o driver ODBC para o MySQL. Clicando no botão Concluir temos a janela de configuração do driver ODBC, que deve ser preenchida de acordo com os valores apresentados na Figura 4.2.

Figura 4.2. Janela de configuração do Driver ODBC.

Os campos Data Source Name, Server, User e Password devem ser preenchidos para que possamos escolher um banco de dados no campo Database. É aconselhável clicar no botão Test para verificar se a conexão foi realizada com sucesso e, caso negativo, pode-se clicar no botão Diagnostics >> para verificar qual é a mensagem de erro que foi retornada pelo MySQL. Deste modo, criado um DSN chamado TestMySQL que aponta para o banco de dados REPLICA_MYSQL, que será o destino dos dados utilizados na replicação.

Passo 5: Habilitando o DSN

Após a criação do DSN que utiliza o driver ODBC para acessar o MySQL é preciso indicar para o SQL Server que este DSN pode ser utilizado em uma replicação. Para realizar este passo é preciso acessar a janela de configurações do servidor, através do clique com o botão direto do mouse no nome do servidor dentro do Enterprise Manager, e escolher a opção Propriedades, como a Figura 5.1 mostra.

Figura 5.1 Acessando as propriedades do servidor.

Com a janela de configurações do servidor aberta, apresentada na Figura 5.2, devemos selecionar a aba Replication e clicar no botão Configure… Esta nova janela contém as propriedades do Publicador e do Distribuidor e devemos clicar na aba Subscribers para indicar que o DSN chamado TesteMySQL poderá ser utilizado como assinante. A Figura 5.3 apresenta a janela de propriedades do Publicador e do Distribuidor, com a aba Subscribers selecionada.

Figura 5.2. Janela de propriedades do servidor.

Figura 5.3 Janela de propriedades do Publicador e Distribuidor.

A partir da janela apresentada na Figura 5.3, devemos clicar no botão New… para habilitar um possível novo assinante para o Publicador. Não é preciso selecionar o assinante PICHILIANI na lista, basta clicar no botão New…

A tela apresentada após o clique no botão New… mostra todos os tipos de assinantes que o SQL Server 2000 suporta: SQL Server Database, Microsoft Jet 4.0 database (Microsoft Access), OLE DB data source e ODBC Data Source. Devemos escolher a última opção, ODBC Data Source, conforme a Figura 5.4, e clicar no botão OK.

Figura 5.4. Habilitando um novo tipo de assinante.

Para finalizar a habilitação do novo assinante basta escolher o nome DSN TesteMySQL e especificar o login root com a sua senha na janela de configuração do DSN escolhido, de acordo com a Figura 5.5. Após clicar no botão OK da janela apresentada na Figura 5.5 basta selecionar o assinante TesteMySQL e clicar nos botões OK das duas janelas abertas até agora. Com esta configuração o SQL Server estará pronto para utilizar o MySQL apontado pelo DSN TesteMySQL como um assinante de uma publicação.

Figura 5.5. Especificando a conexão do DSN TesteMySQL.

Com o término do passo 5 a replicação já pode ser configurada. O próximo passo que veremos envolve a criação da publicação no SQL Server, onde especificaremos qual tabela deverá ser replicada e como.

Um grande abraço e até a próxima pessoal