Olá pessoal.
Nota: A migração deve obrigatoriamente ser feita primeiro em ambiente TESTE.
O Primeiro passo é instalar o Protheus 10, não entrarei em detalhe, mais tarde faço um tutorial sobre como instalar o Protheus 10. Após instalação do Protheus 10, faça uma atualização completa da instalação (https://raphaelpilatti.wordpress.com/2009/11/04/atualizacao-completa-protheus-10).
Faça uma cópia da pasta SYSTEM/SIGAADV da versão anterior (seja ela 7.10, 8.11 ou até mesmo 10.1 R1.1/R1.2) e cole dentro da pasta de instalação do Protheus 10 que acabou de ser instalado.
Crie um Banco de Dados TESTE e o atualize com os dados da produção.
1º – Acesse o TotvsSmartClient.exe e preencha as informações conforme figura abaixo:
2º – Na próxima tela cliente em avançar.
3º – Na tela a seguir informe a senha do Administrador e pressione a tecla TAB.
4º – Ao pressionar a tecla TAB o sistema apresentará uma nova janela. Escolha qual migração deseja fazer e pressione OK.
5º – Nesta tela marque a opção SIMULAÇÃO. Nesta opção o update irá verificar todos os SX’s e tabelas, porém as tabelas não serão alteradas. Caso encontre algum erro o update irá apresentar um log de erros. Após marcar SIMULAÇÃO clique em avançar.
6º – A tela a seguir apresenta as empresas que serão migradas. Estas empresas vêm do arquivo sigamat.emp. Clique em avançar.
7º – Na tela a seguir a única opção que deve estar marcada é Log de Critical Error
8º – Nesta tela o update apresenta uma listagem das empresas/filiais envolvidas e também das tarefas a serem executadas. Clique em avançar.
9º – Após verificação das inconsistências, o update apresentará a tela a seguir com os erros encontrados. TODOS os erros devem ser corrigidos para que o update consiga executar todas as tarefas. Abaixo apresentarei alguns erros comuns e suas soluções. Lembro que podem aparecer outros erros além desses, nesse caso poste comentários que resolvemos as dúvidas.
9.1 – O gatilho RBH_HABIL seqüência 005 esta duplicado;
Solução: Acesse o apsdu, abra a tabela (DBF / CTREE) SX7 da empresa em questão e filtre pelo campo apresentado no log. Verifique se o gatilho realmente está duplicado, ou seja, se existe outro EXATAMENTE igual. Caso esteja igual DELETE uma das linhas, se não estiver igual mude a SEQUÊNCIA do gatilho, assim o update não encontrará erro neste gatilho.
9.2 – A chave de índice AKI ordem 1 registro 4359 esta duplicada;
Solução: Acesse o apsdu, abra a tabela (DBF / CTREE) SIX ou SINDEX da empresa em questão e filtre pelo campo apresentado no log. Verifique se o índice realmente está duplicado, ou seja, se existe outro EXATAMENTE igual. Caso esteja igual DELETE uma das linhas, se não estiver igual mude a SEQUÊNCIA do índice, assim o update não encontrará erro neste índice.
9.3 – O tamanho do campo AF8_OBS arquivo AF8010 e diferente do dicionário;
Solução: Acesse o apsdu, abra a tabela SX3 da empresa em questão e compare o tamanho do campo como tamanho do campo no Banco. Caso o tamanho do Campo no SX3 seja maior, copie a tabela para DBF / CTREE e drope-a. Caso o tamanho do campo no Banco seja maior, altere o tamanho do SX3.
9.4 – O campo PJ_NMARCS não existe no arquivo SPJ010;
Solução: Acesse o apsdu, abra a tabela (TOP) da empresa em questão e caso não tenha dados apenas drope-a, se possuir dados copie para DBF / CTREE e depois faça o drop.
9.5 – O campo YN_FILIAL não existe no arquivo SIG010;
Solução: Neste caso a tabela SYN está apontando para o arquivo (tabela banco) SIG010 e por isso não encontra os campos da tabela SYN. Acesse o apsdu, abra o SX2 (DBF / CTREE) da empresa em questão e altere o X2_ARQUIVO para SYN.
9.6 – O campo de usuário RCT_FILIAL existe na versão padrão e será substituído pelo campo da versão;
Solução: Acesse o apsu, abra a tabela SX3 (DBF / CTREE) da empresa em questão a apague o conteúdo do campo X3_PROPRI.
Após correção de todos os erros apresentados no log repita o passo 1. O sistema apresentará uma tela perguntando o que gostaria de fazer, uma vez que o update está sendo executado em modo SIMULAÇÃO. Escolha a opção CONTINUAR, até que o update finalize sem apresentar log de erros.
Repita os passos anteriores até que o update não apresente mais erros.
10º – A tela abaixo mostra que o update foi finalizado em modo SIMULAÇÃO. Neste momento escolha a opção REINICIAR.
11º – Repita os passos 1, 2, 3 e 4. Na tela a seguir NÃO marque a opção SIMULAÇÃO. Nesta opção o update irá alterar as tabelas do Banco de Dados.
12º – Após finalização do processo sem erros o update apresentará a tela a seguir. Clique em Finalizar.
13º – Acesse o SIGACFG, com isso o sistema irá refazer os índices dos arquivos customizadores (SX’s) e também será necessário escolher a localização, conforme figura abaixo. O processo deve ser feito para todas as empresas.
14º – Ainda no SIGACFG , acesse Base de Dados -> Dicionario -> Stored Procedure
15º – Escolha a opção Desinstalar e clique em OK.
16º – Marque todas as empresas e clique em OK.
17º – Aparecerá a mensagem abaixo.
18º – Repita o passo 14 e escolha a opção Instalação
19º – Marque novamente as empresas e clique em OK.
20º – Aguarde o fim do processo.
21º – Como foi necessário retirar algumas tabelas durante a migração, devemos agora retornar essas tabelas para o sistema, porém somente os dados devem ser retornados, pois a estrutura está diferente. Para isso faça o seguinte. Acesse a pasta SYSTEM / SIGAADV e edite um menu de módulo (Ex: SIGAFIN.XNU). Dentro do menu inclua as tabelas que deseja “retornar” ao sistema, ou melhor, recriar para retornar os dados.
As tabelas devem ser adicionadas nas tags:
SA2
Exemplo: Caso queira adicionar a tabela SE1, faça uma cópia da tag acima e altere o nome da tabela.
SE1
Depois de adicionar todas as tabelas que deseja retornar os dados salve o arquivo XNU e acesse o módulo, no qual o menu foi alterado.
22º – Execute o TotvsSmartClient e informe o módulo que o foi alterado.
23º – Acesse Consultas -> Cadastros -> Genéricos
24º – Escolha a tabela que deseja recriar e retornar os dados e clique em OK.
25º – O sistema apresentará a tela abaixo, neste ponto o sistema já criou a tabela com a estrutura correta, porém sem os dados.
26º – Acesse o apsdu, e abra a tabela que deseja restornar os dados. Acesse o menu Utilitário -> Append From
27º – Escolha o DRIVER (DBF / CTREE) e clique no botão … (3 pontos … (diretório)), para apontar onde está a tabela salva durante a migração e clique em OK.
O sistema deverá apresentar a mensagem abaixo quando o processo finalizar com sucesso.
28º – Após estes passos somente é necessário que os fontes customizados sejam compilados no novo repositório. Faça isso através do TotvsDevStudio. Neste momento o processo de migração está finalizado, e a partir de agora o sistema deve ser validado.
Espero que o tutorial ajude.
Qualquer dúvida postem aqui que eu respondo.
[]’s
Raphael D. PILATTI