MIT072 Conversao P11 PDF

MIT072 – Manual de Operação do Protótipo
Conversão/Atualização Release - Protheus Revisão 008 – 29/02/2011

Roteiro para conversão ou atualização de release para o produto TOTVS MICROSIGA PROTHEUS 11 ou superior
Elaboração: Fabricio Amaro – Unidade TOTVS OP – Bauru – fabricioamaro@totvs.com.br
Colaboração: Gustavo Canela – Unidade TOTVS OP – Bauru – gscanela@totvs.com.br

Modo de Compartilhamento das tabelas
Victor Nigro – Unidade TOTVS OP – Bauru – jose.vasques@totvs.com.br

Copiar via linha de comando direto do Linux
Daniel Peixoto da Silva – Unidade TOTVS OP – S. J. Rio Preto – dsilva@totvs.com.br

Collation diferentes
Marco Smanioto – Unidade TOTVS OP – Bauru – marcosmanioto@totvs.com.br

Rotina de ajuste das tabelas
Evandro Galindo – TOTVS SP – São Paulo – evandro.galindo@totvs.com.br – 12/01/2012

Collation diferentes: criar uma database limpa e importar as tabelas.
Ederson Guerra – TOTVS OP – Bauru - edersonguerra@totvs.com.br – 23/02/2012

Rotina para ajustar os campos das tabelas compartilhadas pelo SX2
Rodrigo Pedroso – TOTVS OP – Bauru - rppedroso@totvs.com.br – 27/02/2012

Tamanho dos campos numéricos alterados após a conversão
Sérgio Passerini – TOTVS OP – Bauru – sergio.passerini@totvs.com.br – 28/02/2012

Problemas na tabela SX5
Conforme orientações do chamado SCUMQY, a conversão para a versão 11 segue os mesmos procedimentos que a 10, mudando apenas o
nome da função a ser executada.
Para deixar bem detalhado todos os procedimentos a serem executados, foi desenvolvido esse manual para que a conversão saia da melhor
maneira possível. Foi desenvolvido com base em históricos de conversões na prática, ou seja, estão relatados quase todos os possíveis
problemas que podem ocasionar um erro de conversão.
Observação extremamente importante: Esse documento não está OFICIALIZADO pela TOTVS matriz, portanto, deverá ser seguido apenas
como um guia. Os nomes aqui citados são de pessoas que possuem grande experiência no referido assunto, mas apenas ajudaram no
complemento de informações desse manual, portanto, não são corresponsáveis pelas aplicações dos procedimentos. Sendo assim, reforçamos
a necessidade de efetuar um backup de toda a base de dados.
Sugerimos a leitura INTEGRAL desse documento, antes de iniciar a conversão, inclusive os itens relacionados aos problemas pós-conversão.
MIT072_Conversao_P11.doc Página 1 de 28
Antes de iniciar a conversão, executar/analisar no ambiente atual do Protheus 10:
1) Espaço em disco:
O espaço em disco livre deve ser de aproximadamente 3 vezes o tamanho atual da pasta System somado ao tamanho do banco de dados.
Ou seja, se a sua database estiver com 4,5 GB, e a pasta system estiver com 500MB, então, o seu espaço em disco livre deverá ser de
aproximadamente 15 GB.
Isso se faz necessário devido ao fato do Protheus efetuar backups de cada tabela (ou mesmo criar tabelas) no momento da conversão,
tanto no BANCO DE DADOS (se for observado, serão criadas as tabelas com _BKP, exemplo, SRA010_BKP) como também na pasta SYSTEM
e SYSTEMLOAD.
2) Fazer um backup da pasta Protheus_Data e do banco de dados.
3) Checar a duplicidade de registros:
a. Baixar do portal o arquivo SX2.UNQ e a patch da rotina CheckDupl, e colocar na systemload do ambiente a ser convertido.
b. Executar a rotina CheckDupl (obs. A rotina não pode ser chamada pelo FORMULAS, tem que incluir no menu do módulo
CONFIGURADOR (sigacfg.xnu):
<MenuItem Status="Enable">
<Title lang="pt">CheckDupl</Title>
<Title lang="es">CheckDupl</Title>
<Title lang="en">CheckDupl</Title>
<Function>CHECKDUPL</Function>
<Type>1</Type>
<Access>xxxxxxxxxx</Access>
<Module>99</Module>
<Owner>13</Owner>
</MenuItem>
c. Ajustar os registros duplicados (se houver)
4) Backup e remoção dos índices de usuários - SIX:
a. Abrir, via MPSDU, o arquivo SIXEE0.ext (EE = Empresa | ext = DBF ou DTC)
b. Filtrar pelo campo PROPRI diferente de “S”
c. Copiar para um arquivo de backup (o nome que desejar).
d. Apagar esses índices. Os mesmos não poderão ser utilizados na conversão.
Obs.: Será necessário voltá-los ao arquivo de índice ao final da conversão, atentando-se a seqüência informada pelo sistema. Isso quer
dizer que também será necessário corrigir esse índice e seqüência nos rdmakes (fontes customizados) que utilizem os mesmos, e que indicam o
número do índice ao invés do nickname do índice.
5) Apagar todos os arquivos de índices das pastas do Protheus_Data.

a. Faça uma busca pela extensão. Entendem-se os arquivos de índices: *.CDX ou *.IDX.
b. Em casos de base CTREE, são criadas pastas com o nome e extensão .idx, exemplo: sc62990a.idx. Pode apagá-las.
c. Apagar o conteúdo das pastas “ctreeint”. Normalmente são 2 pastas, sendo uma no Protheus_Data e a outra na System.
d. Apagar o índice do ARQUIVO DE EMPRESAS (arquivo SIGAMAT.IND).
6) Apagar os arquivos de LOG e TEMPORÁRIOS

a. Faça uma busca pela extensão *.LOG e *.TMP
7) Na pasta “SYSTEMLOAD”, exclua os arquivos *.DBF e *.IDX.
8) Apagar os arquivos da pasta temporária do Windows (Windows > Executar > %TEMP%). Se não apagar irá influenciar nos arquivos
temporários do Protheus, e pode ocasionar erros.
Dica para agilizar a conversão: Muitos clientes utilizam a empresa 99 para testes, e em muitos casos nem é mais utilizada. A sugestão é excluir
os arquivos DBF ou DTC dessa empresa, e apagar a empresa do Cadastro de Empresas (abra o arquivo SIGAMAT.EMP via MPSDU, e apague a
mesma).
Início do Protheus 11
9) Instalar e subir os serviços do Protheus 11. Atualizar com todos os pacotes mais recentes possível.
a. RPO - Categoria: Repositório de Objetos
b. BUILD - Categoria: Binário TOTVSTec
c. UPDATE - Categoria: Update de Programas
d. PATCH/LIB DE PROGRAMAS - Categoria: Path de Programas
e. HELP - Categoria: Help de Campo/Pergunta
f. MENUS - Categoria: Menu de módulo. Contempla os arquivos XNU. Esses arquivos deverão substituir os da pasta SYSTEM,
porém, fazer um backup antes para, após a conversão, poder comparar e incluir os menus customizados.
g. BRA.ZIP - Categoria: Dicionário de dados. Esse arquivo contém o arquivo SXBRA.TXT, que é o dicionário de dados padrão do
Protheus
h. Descompactar o conteúdo da pasta ACE_8.00 na pasta bin\appserver\. Atenção: somente essa pasta!
i. Certifique-se que o servidor tenha espaço em disco o suficiente para a conversão. Recomenda-se, no mínimo, um espaço 3 vezes
superior ao da base atual (soma da pasta SYSTEM e a base de dados). Isso se faz necessário pois o Protheus cria arquivos
temporários no momento da conversão.
10) Descompacte os arquivos de “HELP” e “BRA.ZIP” na pasta “SYSTEMLOAD” da base a ser convertida. Deverá substituir os arquivos
existentes.
Obs.: cuidado com os servidores do Protheus que tenham o sistema operacional LINUX, pois quando o arquivo é copiado pelo programa
WinSPC (por exemplo) o arquivo pode ser corrompido. Sugestão: copiar via linha de comando diretamente do Linux.
Caso queira, utilize o programa 7-Zip (programa tipo Winrar e Winzip). Gere um arquivo tipo TAR antes de copiar para o Linux, e faça
a transferência (cópia). Para descompactar no LINUX utilize a sintaxe: tar -xvf nomedoarquivo.tar
Como saber se deu problema? No inicio da conversão, após clicar em Avançar e apresentar a tela de progresso, o sistema irá criar na
pasta “systemload” os arquivos do dicionário de dados (SX2, SX3, etc.), exibindo a mensagem:
Observar nessa pasta e, caso demore a criar os arquivos ou mesmo o tamanho desses arquivos não tiverem sendo alterado (para
maior), quer dizer que o arquivo TXT está corrompido, e a conversão simplesmente está parada. Sendo assim, encerrar o processo
reiniciando o Server.
Dica: Em casos dos clientes que utilizam apenas o ambiente em linguagem PORTUGUES, dos arquivos de HELP de Campo/Pergunta, deixe
apenas o arquivo HLPPOR.TXT. Dessa forma a conversão será mais rápida, pois não irá atualizar os arquivos de help de campo espanhol e
inglês.
11) Caso tenha um TOP Connect mais atualizado, também baixar, instalar e configurar. O mesmo deverá apontar para o banco de dados a ser
convertido. No caso do Protheus 11, deverá ser utilizado o TOTVS DBAccess. Se não utilizar um DBAccess atualizado, terá sérios
problemas. Se quiser utilizar 2 TOP’s, pode-se configurá-los para compartilhar as licenças, colocando essas configurações nos INI’s dos
Server’s dos TOP’s:
[General]
Licenselimit=nnn
Onde nnn é o limite de licenças que vai consumir do License Server.
12) No arquivo “appserver.ini” do Protheus 11, criar um ambiente que aponte para o ambiente a ser convertido. Exemplo:
[TOTVS_10_PARA_11]
SourcePath = C:\TOTVS 11\Microsiga\Protheus\APO ;tem que ser o APO da versão 11
RootPath = C:\Protheus_Data ;apontar para o ambiente OFICIAL a ser convertido
StartPath = \system\
x2_path =
RpoDb = SQL
RpoLanguage = Portuguese
RpoVersion = 110
LocalFiles = ads
Localdbextension = .dbf
PictFormat = DEFAULT
DateFormat = DEFAULT
TopDataBase = MSSQL7
TopServer = LOCALHOST
TopALIAS = TOTVS_10_11 ;nome do ALIAS criado no TOP – ambiente OFICIAL
RegionalLanguage = BRA
Helpserver = localhost:8687
Obs. extremamente importante: Não utilize esses espaços e “;” em servidores com S.O. Linux.
13) Arquivo de Senhas.
Na conversão de testes apresentaram erros no arquivo de senhas. A solução é simples:

a. Apagar o arquivo sigapss.spf da pasta SYSTEM
b. Apagar os arquivos da pasta “profile” do Protheus_Data
Dessa forma, a senha do Administrador a ser utilizada será “em branco”.
Após a conversão, abrir o SIGACFG – Configurador, cadastrar a POLÍTICA, no menu Senhas, e após cadastrado, sair do CFG, ir na pasta de
backup, copiar o arquivo SIGAPSS.SFP e a pasta “profile” inteira, e substituir na base convertida.
O procedimento de copiar o sigapss e o profile foi passado pela TOTVS no chamado SCTXW5, e funcionou normalmente.
A dica de apagar o sigapss antes do inicio da conversão foi minha, pois na conversão o sistema não altera o arquivo. Achei então mais fácil
fazer dessa forma, pois utilizando o padrão era apresentado erro (mas que não impediu a conversão).
14) Antes de iniciar a conversão, sugiro analisar os erros de conversão listados no item 20 desse manual. Dessa forma já se elimina alguns
erros que serão apresentados na conversão.
15) Inicio da conversão.
Seguido todos esses passos corretamente, poderá ser executado o smartclient.exe do Protheus 11, passando o seguinte Programa Inicial:
MP710TO110
Utilizando o arquivo de senha padrão (sem apagar o sigapss.spf), ao digitar a senha, deu erro:
Porém, tentando novamente, digitei a senha, e passou.
16) Selecione de qual versão será originada a conversão.
Conversão: Atualização de release:
Obs.: Não foram feitos teste com a versão 8 nem com a 7, então, não se sabe os riscos que implicariam. Vale lembrar que da versão 7 ou 8
para a 10, existem detalhes específicos a serem analisados, tais como alteração de algumas variáveis:
a) ValidPerg ou cPerg: tamanho de 6 para 10 - PADR(cPerg,10)
b) cUsuario: essa variável não é mais utilizada, portanto deverá ser trocada para cUserName.
Obs. Importante: Após selecionar o tipo de conversão e clicar o OK, é criado o arquivo “mpupd.tsk” na pasta Appserver do Protheus 11.
Esse arquivo grava os passos da conversão, e se, for necessário re-iniciar a conversão, o Protheus utiliza esse arquivo para dar
continuidade.
O mesmo só poderá ser apagado se a conversão for iniciada do ZERO.
Se a tela para seleção de qual versão será originada a conversão não aparecer, é porque existe esse arquivo na pasta APPSERVER.
17) Configuração de execução do Update: Normalmente são marcadas as opções conforme imagem abaixo, mas isso não é uma regra, pode
variar conforme a necessidade de cada empresa/usuário.
18) Será apresentada a tela com as empresas que serão convertidas:
19) Ao clicar em AVANÇAR, a conversão terá início.
20) Se houver erros na conversão será apresentada a tela:
Emitir o relatório para analisar os erros. Finalizar a conversão.
Obs.: segue abaixo relação dos erros que foram apresentados na conversão da base de testes (sem customizações):
O gatilho AK2_CC sequencia 001 esta duplicado

O gatilho AK2_CLVLR sequencia 001 esta duplicado
O gatilho AK2_CO sequencia 001 esta duplicado
O gatilho AK2_ITCTB sequencia 001 esta duplicado
O gatilho QAA_RECUR sequencia 001 esta duplicado
A chave de indice BMA ordem 2 registro 1430 esta duplicada
A chave de indice CDM ordem 5 registro 10059 esta duplicada
A chave de indice CDM ordem 6 registro 10060 esta duplicada
Chave duplicada na tabela TRX990, existem procedimentos especificos a serem adotados, consulte o HelpDesk Microsiga, mensagem
SQL Error: 1505 (23000) - RC -1 - [Microsoft][ODBC SQL Server Driver][SQL Server]A instrução CREATE UNIQUE INDEX foi
encerrada porque foi encontrada uma chave duplicada para
O tamanho no SX3 do campo VI0_LOJFOR é dIferente do SXG
O tamanho no SX3 do campo VI0_LOJFOR é infeiror ao limite do SXG
O tamanho no SX3 do campo AKX_CC_INI é dIferente do SXG
O tamanho no SX3 do campo AKX_CC_FIN é dIferente do SXG
O tamanho no SX3 do campo RFF_CC é dIferente do SXG
O tamanho no SX3 do campo RFG_CC é dIferente do SXG
O do tamanho no SX3 campo EK_NUMOPER é dIferente do SXG
O tamanho da pergunta 07 do grupo MTA996 é dIferente do SXG
A chave de indice BMA ordem 2 registro 1430 esta duplicada
A sugestão é que, antes do início da conversão, seja visto esses problemas.
21) Como resolver os erros de conversão: abrir o MPSDU (se já iniciou a conversão, abra pelo Protheus 11 mesmo. Ver um pequeno detalhe
em Observações finais).
a. Em casos de GATILHOS com seqüência duplicada, abrir a tabela SX7EE0.ext, filtrar pelo gatilho mencionado, e apagar os que
estiverem duplicados.
b. Em casos de INDICES duplicados, abrir a tabela SIXEE0.ext, filtrar pelo índice mencionado, e apagar os que estiverem duplicados.
c. Quando o erro referenciar a tabela SXG, significa que o campo está em desacordo com a tabela de GRUPO DE CAMPOS (SXG).
Exemplo:
O do tamanho no SX3 campo EK_NUMOPER é dIferente do SXG
Nesse caso, abrir a tabela SX3 (em casos de Campos de tabelas) ou SX1 (em casos de campos de Perguntas), filtrar o campo
mencionado, e na coluna X3_GRPSXG ou X1_GRPSXG, apagar o conteúdo desse campo, para que o mesmo não faça mais parte desse grupo de
campos.
Obviamente, deverá voltar essa informação após a conversão, e analisar os detalhes. O mais recomendado é fazer essa análise antes
da conversão.
Obs.: EE = Empresa | ext = DBF ou DTC
Obs. 2: os erros de português são do próprio sistema.
d. Quando o erro é referente a chave duplicada na tabela, quer dizer que o CHECKDUPL não foi executado. Para resolver isso, deverá
saber qual o X2_UNICO da tabela, e, via banco, fazer um select nessa tabela e ver qual o registro que está duplicado.
No exemplo desse log (em destaque vermelho), foi simples resolver: abri a tabela pelo MPSDU, e apaguei os dados da mesma, pois se
tratava de uma tabela sem uso.
Obs.: Ao sair da tela que apresenta os erros de conversão, apresentou o seguinte error.log (no caso de não ter apagado o arquivo sigapss.spf):
22) Iniciado novamente a conversão - Sem apagar o arquivo MPUPD.TSK da pasta appserver..
Conforme mencionado anteriormente, como se manteve o arquivo MPUPD.TSK, não será apresentado a tela de seleção da origem da
conversão, conforme item 15 desse boletim.
Obs.: Se for apresentada uma tela mencionando que houve erros na conversão, seguir os procedimentos mencionados na mesma, e
continuar a conversão. Essa mensagem normalmente só é apresentada em casos de erros críticos, tais com exemplo, índices duplicados.
Depois da conversão...
23) Acessar o SIGACFG para que o sistema recrie as estruturas dos índices. Acessar todas as empresas. Se não fizer isso poderá dar erro ao
tentar acessar algum cadastro do sistema (Erro de tabela exclusiva).
24) Arquivo de índices: conforme item 4 desse documento.
Abrir via MPSDU o novo SIX, e também o arquivo do backup. Filtrar os índices e analisar quais alterações o compatibilizador fez e quais
alterações você deverá fazer no arquivo de backup.
Exemplo prático. (Esse índice é só um exemplo. O mesmo não sofreu tal alteração).
Antes da conversão:
Conforme orientação no item 4, o índice 6 seria copiado para uma tabela de backup e excluído dessa tabela principal.
Após conversão:
Observem que o compatibilizador criou o índice 6, com o PROPRI = “S”.
Sendo assim, na tabela de backup, deverá abrir a mesma e alterar a ordem do índice, nesse exemplo, pra 7:
Após analisar todos os índices, poderá então dar um “append” na SIX principal, com os arquivos contidos no backup.
A sugestão é que antes do “append” seja feito um backup da SIX principal.
25) Revisão dos índices
Revise os índices dos fontes customizados, conforme as alterações executadas no passo 24 e indicação no item 4.
Rev. 008: Normalmente, os fontes personalizados que apontam para os índices que foram criados pelos usuários, utilizam o DbSetOrder
ou SetOrder, e se na conversão essa ordem foi alterada, deverá rever/ajustar todos os fontes.
Em alguns casos/fontes é utilizada a função SetNickName, mas isso não indica que não deverá ser revisado o campo NICKNAME, pois a
TOTVS não possui um padrão para dar nomes em alguns índices, consequentemente, pode conflitar com o que foi criado pelo usuário.
26) Novo controle de GRUPO DE EMPRESAS.
Para atender ao novo conceito de empresas, filiais e unidades de negócio, foram inclusos 2 novos campos no arquivo SX2.
Porém, observe que se trata de campos OBRIGATÓRIOS.
Se for necessário dar manutenção em alguma tabela, ao tentar confirmar a alteração, deverão informar esses novos campos.
Para que isso não ocorra, execute o MPSDU, abra o arquivo SX2, e execute um “replace” nos campos X2_MODOUN e X2_MODOEMP com
o mesmo conteúdo do campo X2_MODO.
Obs. Importante: Na conversão o sistema não irá alterar o tamanho do campo “_FILIAL” das tabelas, será mantido o padrão de 2 e as
regras de empresa e filial. Não é necessário fazer nenhum tipo de tratamento. Veja o exemplo do SX3 após conversão:
Rev. 008: Outro item importante que deverá ser observado é que a tabela SX2 não está mais exclusivamente apenas na estrutura do dicionário
(pasta system), mas também está no BANCO DE DADOS, veja:
Portanto, os ajustes citados acima, também deverão ser feitos nessa tabela SX2 do BANCO DE DADOS.
Novo Grupo de Empresas: Quando for criar uma nova empresa no Configurador (GRUPO DE EMPRESAS), deverá seguir os novos
padrões e exigências. Exemplo: ao se criar um novo Grupo de Empresas, e definir o tamanho 6 e seu respectivo leiaute, o campos “_FILIAL”
automaticamente serão criados com o tamanho 6. Veja o exemplo:
Rev. 008: No link abaixo existem alguns procedimentos explicando sobre o novo conceito de GESTÃO DE EMPRESAS:
http://www.totvs.byyou.com/artigos?app_ByYouSocialArticle_articleId=79501100&space=advpl
Se após a conversão você desejar mudar a estrutura das tabelas para atender a esse novo conceito, existem procedimentos técnicos que
precisam ser realizados com muita cautela. Vide/solicite boletim específico para esse caso.
27) Executar os passos de criar a política de senhas conforme passo 13. Se necessário, copiar do backup do Protheus_Data o arquivo
SIGAPSS.SPF e a pasta “profile”, e substituir o da pasta convertida.
28) Substituir os arquivos de menu da pasta system (*.XNU) pelos baixados do portal. Antes, fazer um backup para, após a substituição,
analisar as customizações/particularidades.
29) Folha de Pagamento – Roteiro de cálculo
Quando há uma conversão, é necessário apagar o roteiro e fazer com que o sistema recrie o padrão. Para isso:
a. No MPSDU, abra a tabela SRM, copie para um backup as linhas que não são do sistema. Para diferenciar uma linha customizada
de uma linha padrão do sistema, poderá filtrar, utilizando a expressão, da seguinte forma:
SUBSTR(RM_SEQ,5,1) <> "0"
Obviamente deverá ser analisado com mais cautela, pois pode haver alterações em linhas que terminem com 0. Há casos onde
os analistas colocam “*” no campo RM_DESCRIC.
b. Após feito o backup, deletar os registros.
c. Entrar no SIGAMDI, e acessar o módulo GESTÃO DE PESSSOAL > ATUALIZAÇÕES > DEFINIÇÕES CALCULO > ROTEIROS CÁLCULO.
Com esse procedimento o sistema irá recriar os valores da tabela SRM, porém, no seu padrão. Aproveite para acessar os demais
menus do item Definições de Cálculo, tais como Definição Tabela, Mnemonicos, etc, pois existem procedimentos técnicos
internos nessas rotinas que são executados quando acessado os mesmos.
d. Em seguida, voltar ao MPSDU, e dar um “append” na SRM com o arquivo de backup, para aplicar as linhas customizadas do
cliente.
e. Nas linhas customizadas, alterar o campo RM_VERSAO para igual a criada pelo sistema. A versão do Protheus 11 é “194” até essa
data.
30) Verificar os fontes customizados
Pra quem utiliza alguns pontos de entrada que incluem novos botões em rotinas, tal como exemplo, GPE11ROT, relacionada a rotina
GESTAO FUNCIONARIO, deverá ficar atento ao seguinte:
No Protheus 10, funcionava normalmente a rotina da seguinte forma:
User Function GPE11ROT()

Local aArea := GetArea()
Local aRotinas := {}
aFolProc :={{ "Lançam. p/ Verba" , "GPEA100()" , 0 , 6 },;
{ "CNAB (BB)" , "GPEM410()" , 0 , 6 },;
{ "SISPAG (ITAU)" , "GPEM450()" , 0 , 6 },;
{ "Import. Lanc. Mens." , "GPEA210()" , 0 , 6 }}
aAdd( aRotinas, { "Oi*" , "u_oi()" , 6 , , .F. } )
aAdd( aRotinas, { "Processos Folha*" , aFolProc , 6 , , .F. } )
RestArea( aArea )
Return( aRotinas )
Porém, se deixar dessa forma, e compilar o projeto, será exibido erro no momento de entrar na rotina no Protheus 11.
Para corrigir isso, deverá fazer a seguinte alteração (na linha em destaque azul):
aAdd( aRotinas, { "Oi*" , "u_oi()" , 0 , 6 , , .F. } )

aAdd( aRotinas, { "Processos Folha*" , aFolProc , 0 , 6 , , .F. } )
Analise as demais rotinas para saber se estão dessa forma.
Para efeito de testes, essa alteração também foi feita no Protheus 10, e compilada, e a rotina funcionou normalmente.
Orientações conforme o chamado SCUMUO.
31) Compilar o projeto com as customizações do cliente.
32) Aplicação de UPDATES. (Rev. 005)
A execução da virada de versão não garante a aplicação dos updates modulares, como, por exemplo, UPDSIGAFIS, UPDCOM, UPDEST,
sendo esses 2 últimos exemplos com controles seqüenciais (UPDCOM01, UPDCOM03, etc), conforme resposta do chamado SDSFKX.
É sugerida então a execução de todos os updates para que a base fique completamente atualizada.
Como não há como sabermos se tal update já foi executado (exceto as do RH, onde possui a rotina RHUPDMOD), mesmo que antes da
conversão, teríamos então que executar TODOS os updates ou, no mínimo, os módulos que o cliente mais utiliza.
Para que possa haver esse controle, foi desenvolvida uma rotina específica que gera alguns arquivos de LOG, e quando for executado os
updates, essa rotina verifica se o mesmo já foi executado ou não.
Os detalhes da rotina estão no anexo 3.
33) Finalizando: Acessar o SIGAMDI ou ADV, e fazer todos os testes possíveis.
Observações finais.
A. MPSDU
Não estranhar se você abrir o MPSDU e não encontrar o MENU. O mesmo estará no canto superior DIREITO:
Novo menu: Menu padrão:
Isso acontece pois o tema está configurado para CLASSIC. Para voltar ao padrão, abra o SIGACFG e no menu Miscelanea, Configuração de
Tema, mude para STANDARD e confirme. Abra novamente o MPSDU.
Dica: No Protheus 11, quando se digita o usuário ou a senha errado, o mesmo é fechado por completo após o OK. Anteriormente, a tela de
login se mantinha. Já existe um chamado com FNC em aberto - SDEVH3.
B. Folders (pastas) – X3_FOLDER (rev. 007)
Após insistentes testes de atualização para o release 11.5, foi encontrado um pequeno problema que, apesar de não ser tão grave, causa
um desconforto. O sistema não respeita o X3_FOLDER.
Antes da atualização: Após atualização – MP710TO110:
Foram feitos outros testes também sobre as demais informações do campo (tamanho, valid. Usuário, etc, etc) e nesse caso ele manteve o
legado (menos mal). Portanto, sempre façam um backup e posteriormente ajustem o X3_FOLDER.
Rev. 008 - Rotina que ajusta o X3_FOLDER com base no backup:
#INCLUDE 'PROTHEUS.CH'
#include "rwmake.ch"
#include "topconn.ch"
User Function AjFolder()

Local nCpo := 0
Local xArqCorr := "SX3990_BKP" //ARQUIVO SX3 QUE ESTÁ CORRETO
//OBS: DEVERÁ SER CRIADO O INDICE 1 PARA O X3_CAMPO PARA ESSA TABELA - PODE SER UTILIZADO O MPSDU, CRIANDO UM INDICE PERMANENTE
Private cEOL := CHR(13)+CHR(10)
Private cLog := "ARQUIVO DE LOG DE AJUSTE DOS CAMPOS DA SX3 - X3_FOLDER "+cEOL+cEOL
If MsgYesNo( "Iniciar o Processamento de ajuste da SX3 - X3_FOLDER?", "Confirma?" )
SX3->( dbSetOrder(1) )
SX3->( dbGoTop() )
While !SX3->( Eof() )
//VERIFICA A TABELA ORIGINAL

dbUseArea( .T.,, xArqCorr ,"X3SA", .T., .F. )
X3SA->( dbSetOrder(1) )
If X3SA->( dbSeek( SX3->X3_CAMPO ) )
If SX3->X3_FOLDER <> X3SA->X3_FOLDER //SE FOREM DIFERENTES, ALTERA PARA O QUE ESTAVA NO ARQUIVO CORRETO
RecLock("SX3",.F.) //ALTERAR
Replace X3_FOLDER With X3SA->X3_FOLDER
SX3->( MsUnlock() )
//ARMAZENA OS CAMPOS QUE ESTÃO SENDO AJUSTADOS
cLog += X3SA->X3_ARQUIVO + " - " + X3SA->X3_CAMPO + " - " + X3SA->X3_FOLDER + cEOL
EndIf
End
X3SA->( dbCloseArea() )
SX3->( dbSkip() )
EndDo
SX3->( dbCloseArea() )
cArq := "C:\LOG_SX3_X3_FOLDER_"+xArqCorr+".TXT"
Memowrite(cArq,cLOG)
MsgStop("Concluído. Foi gerado o arquivo de LOG: "+cArq,"(AjFolder)")

EndIf
Return .T.
Esse problema está sendo tratado pelo chamado TEPJK1.
C. Colletion diferentes entre a DataBase e a Tabela. – Reforçando: a TOTVS homologa somente o collation LATIN1_GENERAL_BIN
Após a conclusão da conversão, e dado inicio ao uso do sistema, pode ocorrer o seguinte erro (como exemplo):
ERRO THREAD (Lancer, LANCER-PC) 19/01/2011 10:31:25

: Error : 468 (37000) - RC -1 - [Microsoft][SQL Server Native Client 10.0][SQL Server]Cannot resolve the collation conflict between "SQL_Latin1_General_CP437_BIN" and
"Latin1_General_BIN" in the equal to operation. ( From tMSSQLConnection::GetQueryFile )
Thread ID [2580] User [Danilo ] IO [7529] Tables [45] MaxTables [45] Comment [FINA050 - TCPIP] Status [] SP [ ] Traced [No] DBEnv
[MSSQL/dbBotti10Homolog] DBThread [(SPID: 152) ] Started [19/01/2011 10:13:51] IP [192.168.1.105]
SELECT SE2.R_E_C_N_O_ RECTIT,E2_FILIAL,FQ_FILDES FROM SE2010 SE2 , SFQ010 SFQ WHERE E2_PREFIXO = FQ_PREFDES AND E2_NUM = FQ_NUMDES AND E2_PARCELA =
FQ_PARCDES AND E2_TIPO = FQ_TIPODES AND E2_FORNECE = FQ_CFDES AND E2_LOJA = FQ_LOJADES AND SE2.D_E_L_E_T_ = ' ' AND FQ_FILIAL = '01' AND FQ_ENTORI = 'SE2' AND
FQ_PREFORI = ' ' AND FQ_NUMORI = ' ' AND FQ_PARCORI = ' ' AND FQ_TIPOORI = ' ' AND FQ_CFORI = ' ' AND FQ_LOJAORI = ' ' AND SFQ.D_E_L_E_T_ = ' ' on
FIMPEXCTIT(FINXAPI.PRX) 04/08/2010 15:28:02 line : 6898
Isso acontece pois a tabela está com um collation diferente da database:
Para resolver isso, poderá ser feito o seguinte:
i) Criar uma nova database no banco, com o collation correto. Criar as conexões ODBC e no DBAccess para apontarem para essa nova
database. Abrir o MPSDU, e Importar (CTRL + T) as tabelas da database antiga para a database nova. Dependendo do volume de
informações, esse processo pode demorar significativamente. Pode-se utilizar o conceito de Multi-Processo (até 10 jobs), e também
desativar o “Set Deleted” antes de iniciar a importação. Dica do Evandro – TOTVS Matriz.
ii) Utilizar a rotina do Anexo 2.
iii) Abra a tabela via MPSDU, copie os dados para uma tabela de backup, “droppe”, recrie (entrando no sistema), e “append”. Verifique
no banco que os campos ficaram com o mesmo “collation” da Database. Caso isso não funcione, faça o passo ii.
iv) Abra o SQL. Localize a tabela citada no error.log. Clique com o botão direito e escolha a opção Design:
Em cada campo (isso mesmo, em cada campo) na opção Table Designer, troque o collation para “<database default>”:
Feito isso, salve a alteração da tabela, e pode usar o sistema normalmente.
Uma dica simples para saber se o collation do banco está errado, é efetuar uma pesquisa em algum browser (por exemplo, Nome no Cad.
Funcionários), e se o sistema permitir/encontrar alguma informação escrevendo em minúsculo, indica que está errado. Isso porque o collation
LATIN1_GERENAL_BIN é case sensitive, portanto, não encontra valores que não sejam exatamente eles.
Cuidado: se for ajustado o collation do banco, fique atento as rotinas customizadas que utilizem comandos SQL, pois, se estiverem em sintaxe
errada, poderá ocorrer erros nas rotinas. Veja exemplo abaixo:
cQuery := "SELECT NULL AS TAB FROM SYSOBJECTS WHERE ID = OBJECT_ID('"+cTab+"') "

TCQUERY cQuery NEW ALIAS "QTEMTAB"
Essa sintaxe acima funciona pois o banco está no collation errado.
No collation correto, a sintaxe SYSOBJETCS deverá estar escrito em minúsculo:
cQuery := "SELECT NULL AS TAB FROM sysobjects WHERE ID = OBJECT_ID('"+cTab+"') "

TCQUERY cQuery NEW ALIAS "QTEMTAB"
D. Erro de estrutura não existente.
No momento em que o compatibilizador estiver sendo executado, pode ser que aconteça o seguinte erro:
“A estrutura do arquivo \data\LF2010 nao existe no SX3”
Nesse caso o sistema não encontrou os campos na tabela SX3 da tabela citada no erro.
Você pode contornar esse problema de 2 formas:
1) Solicite a alguém os campos da tabela e coloca no seu SX3

2) Apagar essa tabela do SX2 (não aconselhável).
Após essa decisão tomada, reinicie a conversão.
E. Tabelas compartilhadas via SX2 (rev. 008)
Após executar o U_UPDCTB em um cliente, observamos que o sistema literalmente sumiu com um campo da tabela somente no BANCO
DE DADOS, mas ainda existia no SX3.
Após várias analises, concluímos o seguinte:
1) Problema: Quando tentamos acessar o cadastro de Classe de Valor, o sistema exibe o erro de que não existe o campo
CTH_X_NAT.
2) Causa do problema: tabela compartilhada pelo SX2, mas a estrutura da SX3 estão diferentes.
Detalhes técnicos:
SX2010 = CTH = Arquivo = CTH010

SX3010 = CTH = Campo = CTH_X_NAT = Ordem 25 <= OK
SX2020 = CTH = Arquivo = CTH010

SX3020 = CTH = Campo = CTH_X_NAT <= Esse campo não existe na SX3 da empresa 02
Isso ocorre quando o compartilhamento é feito manualmente depois que o campo está criado somente em uma única SX’s.
Na atualização (U_UPDCTB, por exemplo), o sistema efetua um “alter table” com base no SX3 quando existem novos campos.
Quando rodou o upd, o que ocorreu:
Empresa 01
- O sistema alterou a tabela CTH010 com base no SX3010
Empresa 02:
- O sistema alterou a tabela CTH010 novamente (devido ao compartilhamento na SX2020) com base no SX3020 <= Aqui que
houve o problema, pois na SX3 da 02 não tem o campo CTH_X_NAT.
3) Solução:
a) Solicitar para o usuário acessar o cadastro de Classe de Valor e preencher manualmente esse campo (inviável)
b) Correta: abrir a tabela CTH010 do backup, e copiar para DBF ou CTREE. Passos:
I. No MPSDU da base OFICIAL, abrir a CTH010

II. “Droppar” (nesse momento ninguém poderá utilizar o sistema)
III. Acessar o sistema na Contabilidade Gerencial, e abrir esse cadastro para o sistema recriar a tabela CTH com o
campo correto. Nesse momento essa tabela estará em branco.
IV. Abrir novamente o MPSDU, abrir a tabela CTH010, e dar um “append” com a tabela do CTH010 do backup.
O que é importante relatar é que, quando se cria um campo em uma tabela que já estava compartilhada pelo SX2, o sistema não cria
automaticamente na SX3 da outra empresa, sendo necessário cria-lo também nas outras empresas.
Abaixo evidencia dos testes:
1) Tabela SP1 compartilhada entre empresas
2) Campos atuais na SP1 de ambos SX3’s.
3) Criando campo na empresa 01:
Obs.: Apesar do sistema indicar que está verificando as tabelas compartilhadas, ele não criou o campo nos demais SX3.
4) Comprovação:
Concluímos que, com isso, numa atualização que venha a criar novos campos nessa tabela, sem duvidas irá ocorrer do sistema apagar esse
campo P1_X_TESTE no BANCO DE DADOS.
Solução:
1) Manual:
Analisar no SX2 quais são as tabelas que estão compartilhadas, exemplo do filtro abaixo:
Seguindo o exemplo, o que poderia ser feito:
A. Abrir a SX3020, filtrar os campos das tabelas que estão compartilhadas.
B. Apagar esses campos;
C. “Appendar” os campos da SX3010, claro, filtrando somente os das tabelas que estão compartilhadas.
2) Rotina para ajuste automático:
Essa rotina foi enviada pelo colaborador Ederson, mas quem a desenvolveu foi um cliente.
Basta informar os parâmetros de qual empresa deverá ser copiada a estrutura.
Após concluída a rotina, os campos ficam corretos na SX3. Seguindo o exemplo da tabela SP1, veja o LOG:
#INCLUDE 'PROTHEUS.CH'
//ROTINA QUE VERIFICA O SX3 que seria o padrão (no caso o SX3010)
//com o SX3 que estaria desatualizado (SX3020) e cria os campos necessários no mesmo.
//Faz isso somente das tabelas que estão compartilhadas entre as empresas.
//NO MOMENTO DE EXECUTAR A ROTINA, DEVERÁ ESTAR POSICIONADO NA EMPRESA QUE POSSIVELMENTE ESTARIA ERRADO, NO EXEMPLO ACIMA, 02
User Function ValSX3()
Local aTabelas := {}
Local aCampos := {}
Local nAux := 0
Local cCpo := ""
Local nCpo := 0
Local xcEmpCor := "01" //EMPRESA COM O SX3 CORRETO
Local xcEmpAju := "02" //EMPRESA A SER AJUSTADA
Private cEOL := CHR(13)+CHR(10)
Private cLog := "ARQUIVO DE LOG DE AJUSTE DOS CAMPOS DA SX3 - EMPRESA ORIGEM (CORRETA): "+xcEmpCor+ " - EMPRESA AJUSTADA: "+xcEmpAju+cEOL+cEOL
If cEmpAnt <> xcEmpAju

MsgStop("Empresa Incorreta.","(ValSX3)")
Return .F.
EndIf
If MsgYesNo( "Iniciar o Processamento do SX3?", "Confirma?" )
SX2->( dbGoTop() )
//PRIMEIRO ARMAZENA SOMENTE AS TABELAS QUE REALMENTE SERÃO ALTERADAS NA VARIAVEL aTabelas
//DA EMPRESA QUE TEORICAMENTE ESTÁ ERRADA
While !SX2->( Eof() )
If SubStr( SX2->X2_ARQUIVO, 4, 3 ) == (xcEmpCor+"0")
aadd( aTabelas, { SX2->X2_CHAVE, .F. } )
Endif
SX2->( dbSkip() )
End
//AGORA PESQUISA O SX3 DA EMPRESA QUE ESTÁ CORRETO

dbUseArea( .T.,, "SX3"+xcEmpCor+"0","X3SA", .T., .F. )
X3SA->( dbSetOrder(1) )
For nAux := 1 to Len( aTabelas )

SX3->( dbSetOrder(2) )
X3SA->( dbSeek( aTabelas[nAux,1] ) )
While !X3SA->( Eof() ) .And. X3SA->X3_ARQUIVO = aTabelas[nAux,1]
If SX3->( dbSeek( X3SA->X3_CAMPO ) )

RecLock("SX3",.F.)
Else
//MsgStop( X3SA->X3_ARQUIVO + " " + X3SA->X3_CAMPO, "Add Campo" )
//ARMAZENA OS CAMPOS QUE ESTÃO SENDO CRIADOS
cLog += X3SA->X3_ARQUIVO + " - " + X3SA->X3_CAMPO + cEOL
RecLock("SX3",.T.)
aTabelas[nAux,2] := .T.
aadd( aCampos, X3SA->X3_CAMPO )
EndIf
For nCpo := 1 to SX3->( FCount() )
cCpo := SX3->( FieldName( nCpo ) )
SX3->&( cCpo ) := X3SA->&( cCpo )
Next
SX3->( MsUnlock() )
X3SA->( dbSkip() )
End
Next
X3SA->( dbCloseArea() )
cArq := "C:\LOG_SX3_"+xcEmpCor+"_"+xcEmpAju+".TXT"
Memowrite(cArq,cLOG)
MsgStop("Concluído. Foi gerado o arquivo de LOG: "+cArq,"(ValSX3)")

EndIf
Return .T.
Esse problema está sendo tratado pelo chamado TEPJJT.
F. Campos numéricos alterados após a conversão (rev. 008)
Após efetua a conversão, foi observado que o sistema alterou o tamanho de alguns campos padrões, o que poderá ocasionar em erros bem
complexos para serem ajustados. Abaixo segue evidencia dos testes:
1) O campo B1_PPIS está bloqueado para alteração (no padrão):
Porém, como sabemos, podemos ir no MPSDU, abrir o SX3, e mudar o X3_RESERV:
Com isso, podemos agora alterar o tamanho do campo:
2) Foi efetuada a mesma alteração no campo FT_ALIQPIS.
3) Foi alterado também o tamanho do campo B1_QTMIDIA, porém, tal campo não estava bloqueado para alteração, portanto, não foi
necessária a intervenção manual no SX3.
4) Resultado dos campos alterados na base antes da conversão.
5) Após a Conversão/atualização de release (MP710TO110), o campo B1_PPIS e FT_ALIQPIS foram alterados:
6) Possíveis perguntas e respostas:
Quais problemas teremos com isso?

R: Muitos, por exemplo, para os SPED’s foi necessário alterar o tamanho de muitos campos.
Como fazer para ajustar?

R: Somente com um programa que primeiro compare o tamanho do campo da tabela antiga, e posteriormente ajuste, e pegue o valor
do backup. Quem tiver esse programa, por favor, compartilhem.
E o termo do Protheus relacionado ao “respeito ao legado”?

R: Não podemos dizer que o sistema não respeitou, pois o campo B1_QTMIDIA foi mantido a alteração que fizemos, o sistema
somente ajustou “para o padrão” os campos que tiveram intervenção manual.
Esse problema está sendo tratado pelo chamado TEPJJQ, mas não acredito que sejam resolvidos tão cedo.
G. Tabela SX5
Muitos clientes costumam aproveitar a estrutura/conceito da tabela SX5, para criar tabelas específicas, como a do exemplo abaixo:
No Protheus 10:
Acontece que a TOTVS não respeita o mesmo conceito das tabelas customizadas, e acaba criando tabelas também com a chave Z.
Veja as tabelas criadas pelo sistema após a conversão para o P11 (sobrepondo as tabelas criadas acima).
Para esse caso não há solução a não ser revisar quais foram as tabelas que o cliente criou, e refazê-las com outra chave.
ANEXO 1: Roteiro de conversão: Protheus 7 para 8, Protheus 8 para 10 e Protheus 10 R1 para R3
Segue roteiro de uma versão antiga, para possíveis consultas:

Passos para a conversão da versão 7.10 para 8.11
1. Copiar a pasta \ap7\ para uma pasta a ser convertida.
2. Atualizar esta versão 7.10 completamente e baixar o programa e o documento que vai explicar como rodar a rotina que vai eliminar os registros duplicados da base da versão 7.10 antes de iniciar o processo de
conversão. (o ftp que segue vai trazer um patch e um documento explicativo sobre como atualizar o sistema e criar um programa no configurador que execute a rotina de compatibilizacão. ->
ftp://ftp.microsiga.com.br/sistemas/CheckUnique/)
3. Após rodar essa rotina no banco da versão 7.10, instalar a versão 8.11 e atualiza-la completamente.
4. Instalar e atualizar o topconnect versão 4.0 ( e verificar se o seu mp8srv.ini indica que esta usando a dll da versão 4.0).
5. Criar um ambiente no topconnect que aponte para a sua base da versão 7.10 e testar esta conexão dentro do próprio topmonitor.
6. Criar um ambiente na versão 8.11 que aponte para a pasta da versão 7.10 como o exemplo:
[Base710]
SourcePath=c:\Protheus8\apo
RootPath=c:\ap7
StartPath=\sigaadv\
RpoDb=Top
RpoLanguage=portuguese
RpoVersion=811
LocalFiles=ads
localdbextenGsion=.dbf
PictFormat=DEFAULT
DateFormat=DEFAULT
TopDataBase=MSSQL
TopServer=Saturno
TopALIAS=dbDatabase
helpserver=192.168.1.1
Obs: Pode-se sim criar uma pasta na versão 7.10 chamada System e copiar os dados da pasta \SIGAADV\ para ela.. porem para fazer isso será necessário entrar nos arquivos SX2 de cada empresa e mudar o path de SIGAADV
para SYSTEM, e fazer a mesma coisa com o arquivo de parâmetros, alem de deixar o StartPath=\SYSTEM\
Porem, prefiro fazer a conversão usando a pasta original sem realizar esta substituição, deixando para realiza-la após a conversão para a versão 8.11.
7. Copiar para a pasta da versão 7.10 a pasta \systemload\ da versão 8.11 (essa pasta contem o arquivo SXSBRA.TXT que é o dicionário de dados que será utilizado para descompactar as tabelas na pasta \sigaadv\ da
versão 7.10.
8. Remover do arquivo de índices, todos os índices criados pelo usuário, e copia-los num arquivo a parte, pois será necessário volta-los ao arquivo de índice ao final da conversão, atentando-se a seqüência informada pelo
sistema.. isso quer dizer que também será necessário corrigir esse índice e seqüência nos rdmakes que utilizam índices criados pelo usuário e que indicam o numero do indice ao invés do nick do índice.
9. Seguidos estes passos, entre na versão 8.11, digite no programa inicial: mp710to811 e no ambiente o ambiente que foi criado acima (apontando para a base da versão 710).
10. O sistema vai informar que esta versão atualizada permite atualiza o protheus 7.10 para a versão 8.11 R2 (Segundo release) ou então de uma versão 8.11 para o 8.11 R2, escolha apenas primeira opção.
11. em seguida a tela que segue solicita a criação de sindex exclusivo, selecione esta opção.
12. A próxima tela informa quais empresas passarão pelo processo de conversão, verifique se constam todas as empresas. (apenas a empresa “matriz” aparece, as filiais apesar de não aparecerem serão convertidas também
pois pertencem a mesma família de arquivos.)
13. Escolha então na próxima tela as opções de conversão, ou seja, marque “Warning Error”, “Remover arquivos de backup após atualização”,”substituir arquivo de log existente” e “Corrigir erros automaticamente”. (não
selecione “permitir interromper processo de conversão”, pois esta opção faz com que cada um dos passos da conversão solicite interação do usuário para passar para o próximo passo.)
14. Pronto, deixe a conversão seguir sozinha.
15. Após a conversão:

• Volte os índices criados pelo usuário
• Copie o conteúdo da pasta \sigaadv\ da versão 7.10 para a pasta \system\ da versão 8.11.
• Copie o conteúdo da pasta \profile\ da versão 7.10 para a pasta \profile\ da versão 8.11.
• Verifique o path do arquivo sx2 se estah correto e apontando para a pasta \SYSTEM\ ao invés de \SIGAADV\ (o mesmo vale para o aquivo de parâmetros)
• Copie o conteúdo da pasta \RDMAKE\ da versão 710 para a pasta \my projects\ da versão 8.11 e revise os rdmakes que utilizam esses índices.
• Abrir os Menus do systemload da internet na pasta /SYSTEM/
• Apagar o roteiro da folha (SRM010)
• Entrar no cadastro de roteiro para ele criar o padrão
• Voltar o roteiro dos usuários e corrigir a seqüência baseada na seqüência da versao anterior
Possíveis erros:
1) Arquivos da contabilidade são diferentes dos informados em seus dicionários.

R: Verifique se o arquivo de grupos contábeis contem o tamanha correto dos arquivos, esse arquivo contem o tamanho mínimo e o tamanho maximo destes arquivos, se necessário corrija o tamanho do campo de código contábil
no sx3, mate a tabela e a appende.
2) Arquivos insistem em derrubar a conversão, dando erros inesperados. (Comum para tabelas SQ da qualidade.)
R: Renomeie este arquivo e reinicie a conversão, e após a conversão, appende este arquivo apagado com o conteúdo do renomeado, ou copie a tabela pra outra e drope para depois appenda-la a partir desta copia.
3) Sistema trava durante a conversão de arquivos muito extensos.

R: Derrube a conexão e inicie novamente a conversão. Pode haver perda de sincronismo entre server e remote, mas não apague os .log, nem os .tsk, apenas os .cdx devem ser apagados.
4) Algum erro que precise começar tudo novamente.

R: Apague os arquivos com extensão .tsk (arquivo de lista de tarefas da conversão, que serve para saber quais os passos que foram feitos pelo sistema durante a conversão).
Obs: Eis aí a necessidade da copia antes da conversão.. tanto da pasta AP7 quanto do banco, pois se precisar começar tudo novamente é preferível voltar o backup do que uma conversão já iniciada.
5) Erro em append por conta de índices.

R: Verifique os índices criados, podem ter sido duplicados acidentalmente, ou então não constam do arquivo de índices.
6) sistema não entra mais por causa de senha errada, mesmo informando a senha do administrador. (erro corrigido na versão 8.11.009)
R: comece apagando o arquivo de extensão .spf pois este arquivo pode ter sido corrompido durante a conversão. Se ainda assim der errado, apague a pasta \PROFILE\ pois as configurações de usuários podem estar erradas.(é
claro que precisa de uma copia desta pasta a parte.)
Obs: para a conversão de menus de usuários o sistema deixa a desejar na conversão do caminho destes menus, ou seja, nas configurações de usuários os menus de usuários continuarão apontando para a pasta \sigaadv\ ao
invés da nova pasta \system\ criada na versão 8.11.. .para isso existem duas opções: Criar uma pasta \sigaadv\ na versão 8.11 que contenha somente os menus de usuários, ou então entrar via configurador no arquivo de
usuários, e mudar um a um os caminhos de cada um dos menus.
CHAMADO TÉCNICO N.o ABXAFL
It. Área Ocorr. Descrição Cons. Externo An. Alocado Dt. Ocorr.
Boa Tarde, Fabrício.
Segue abaixo os procedimentos para atualização de release:
Passos para Migração de Release – P10 (R1) para P10 (R1.1)
Preparando para a atualização
1. Atualize a Build e o RPO do sistema

Site: http://portaldocliente.microsiga.com.br
Link: Atualizações do Produto
- RPO
Palavra: Protheus10
Categoria: Repositório de Objetos
- BUILD
Palavra: Protheus10
Categoria: Binário TOTVSTec
- UPDATE
Palavra: Protheus10
Categoria: Update de Programas
- PATCH/LIB DE PROGRAMAS
Palavra: Protheus10
Categoria: Path de Programas
2. Atualize o diretório Systemload do sistema
a. Descompacte: Help_de_Campo_Pergunta.zip TBR047-FABRICIO DA

002 N1-FRAMEW2 FeedBack TI3205 DANIEL 04/07/08 13:50
SI
- HELP
Palavra: Protheus10
Categoria: Help de Campo/Pergunta
b. Descompacte: Menu_de_Módulo.zip e Dicionário_de_Dados.zip
- MENUS
Palavra: Protheus10
Categoria: Menu de módulo
- BRA.ZIP
Palavra: Protheus10
Categoria: Dicionário de dados
3. Exclua os arquivos *.DBF do diretório SYSTEMLOAD

4. Exclua os arquivos *.IDX do diretório SYSTEMLOAD
5. Exclua o arquivo *.TSK do diretório APPSERVER do sistema
6. Exclua o arquivo *.LOG do diretório SYSTEM
Atualização da Base de Dados.
OBS.: Para bases TopConnect/DBAccess é necessário executar a rotina CheckDupl.

Para maiores detalhes, entre em contato com o Suporte Help Desk e peça orientações para a execução da
mesma.
1. Execute o SmartClient
2. No campo Programa Inicial digite: MP710TO101
Att,
Daniel.
ANEXO 2: Rotina para ajuste das tabelas:
Essa rotina – xAjTab() - deverá ser chamado via MENU em algum módulo, e pelo SIGAMDI, pois via Configurador ela não é executada, e via
SIGAADV ele carrega as tabelas no inicio do programa, tirando então a exclusividade das mesmas.
#INCLUDE "PROTHEUS.CH"
#INCLUDE "TOPCONN.CH"
#INCLUDE "RWMAKE.CH"
//ROTINA DESENVOLVIDA POR MARCO SMANIOTO E AJUSTADA POR FABRICIO AMARO

//OBJETIVO - RECRIAR AS TABELAS DO BANCO
//EXEMPLO DE USO: EM ALGUNS CASOS, O COLETTION DA TABELA ESTÃO DIFERENTES DA DATABASE, SENDO NECESSÁRIO "DROPPAR" E "APPENDAR" A TABELA. COMO
// É DIFICIL SABER QUAIS TABELAS ESTÃO DESSA FORMA, EXECUTA ESSA ROTINA PARA AS TABELAS QUE DESEJAR
//AS TABELAS DE BACKUP NÃO SÃO APAGADAS POR QUESTÕES DE SEGURANÇA, CASO SEJA NECESSÁRIO RECUPERAR OS DADOS
//SE EXECUTAR 2 VEZES ESSA ROTINA SEM MUDAR O PARAMETRO 'EXTENSAO DA TABELA', SERÁ EXIBIDO O ERRO (NO TOPCONNECT) DE CHAVE DUPLICADA
//NO INSERT DA TABELA OFICIAL E DE BACKUP QUANDO FOR COPIADA DO BACKUP
//NA TABELA DE BACKUP
//SUGESTÃO: ANTES DE EXECUTAR ESSA ROTINA, ABRA O TOPCONNECT E FAÇA O ACOMPANHAMENTO NA ABA MENSAGENS
//Montagem da tela para passagem dos parametros

User Function xAjTab()
Local aSays := {}
Local aButtons := {}
Private cPerg := "XAJTAB1"

Private cCadastro := OemToAnsi( "* Ajusta Tabelas do Banco" )
ValidPerg()
//Apresenta os parametros logo na entrada da rotina
Pergunte(cPerg,.t.)
AADD(aSays,OemToAnsi( " Este programa ira ajustar as tabelas do sistema, fazendo um backup," ) )
AADD(aSays,OemToAnsi( " apagando, recriando e recuperando os dados." ) )
AADD(aSays,OemToAnsi( " Obs.: Executar em modo exclusivo!" ) )
AADD(aButtons, { 5,.T.,{|| Pergunte(cPerg,.T. ) } } )

AADD(aButtons, { 1,.T.,{|o| yAjTab() }} )
AADD(aButtons, { 2,.T.,{|o| FechaBatch() }} ) //FechaBatch é padrão para fechar a tela
FormBatch( cCadastro, aSays, aButtons )
Return
//ROTINA QUE FAZ BACKUP, APAGA, RECRIA E RESTAURA OS ARQUIVOS

USER FUNCTION AJUSTABANCO(cTabela)
//POR GARANTIA, APAGA A TABELA
//FABRICIO - MELHOR NÃO APAGAR A TABELA PARA NÃO TER PROBLEMAS

//EM ALGUNS CASOS PODE DAR ERRO DE INSERT APOS RECRIAR A TABELA ORIGINAL E TENTAR COPIAR DA TABELA DO BACKUP (ACOMPANHAR PELO TOPCONNECT)
//TcDelFile(RetSqlName(cTabela)+"_"+cExt)
cExt := ALLTRIM(MV_PAR03)
cCampos := ""
//PRIMEIRO APAGA OS REGISTROS DELETADOS
cQuery := " DELETE FROM "+RetSqlName(cTabela)+" WHERE D_E_L_E_T_ = '*' "
TCSQLEXEC(cQuery)
//ANALISA QUAIS OS CAMPOS DA TABELA

dbSelectArea("SX3")
dbSetOrder(1)
dbGoTop()
While !SX3->(Eof())
If SX3->X3_ARQUIVO == cTabela .AND. SX3->X3_CONTEXT <> "V"
cCampos += SX3->X3_CAMPO + ","
EndIf
DbSelectArea("SX3")
dbSkip()
EndDo
cCampos += " R_E_C_N_O_ "
//SELECIONA OS REGISTROS PARA BACKUP

cQuery := " SELECT * INTO "+RetSqlName(cTabela)+"_"+cExt+" FROM " + RetSqlName(cTabela)
TCSQLEXEC(cQuery)
//APAGA A TABELA OFICIAL

TCDelFile(RetSqlName(cTabela))
//RECRIA A TABELA ORIGINAL COM BASE NO SX3 DA EMPRESA POSICIONADA

DbSelectArea(cTabela)
dbSetOrder(1)
//RECUPERA OS DADOS DA TABELA DE BACKUP

cQuery := "INSERT INTO " + RetSqlName(cTabela) + " (" + cCampos + ") SELECT "+ cCampos +" FROM "+RetSqlName(cTabela)+"_"+cExt+" "
TCSQLEXEC(cQuery)
//APAGA A TABELA DE BACKUP

//TcDelFile(RetSqlName(cTabela)+"_"+cExt)
Return
Static Function yAjTab()

If MsgBox("Será iniciado agora o processo de ajustes das tabelas do banco. Deseja continuar?","Continua?","YESNO")
Processa({|| zAjTab() },"Processando...")
EndIf
FechaBatch()
Return
Static Function zAjTab()

cAlias := "SX2"
DbSelectArea(cAlias)
dbSetOrder(1)
dbGoTop()
ProcRegua(RecCount()) // Numero de registros a processar
While !SX2->(Eof())
If SX2->X2_CHAVE >= MV_PAR01 .AND. SX2->X2_CHAVE <= MV_PAR02
IncProc("Tabela :" + SX2->X2_CHAVE + " - " + SX2->X2_NOME)
U_AJUSTABANCO(SX2->X2_CHAVE)
EndIf
DbSelectArea(cAlias)
dbSkip()
EndDo
MsgBox("Tabelas ajustadas com sucesso!","Ok","INFO")
Return
Static Function ValidPerg()

_sAlias:= Alias()
aRegs:= {}
dbSelectArea("SX1")
dbSetOrder(1)
cPerg:= PADR(cPerg,10)
// Grupo/Ordem/Pergunta/Perg.Esp/Perg.Ingl/Variavel/Tipo/Tam/Dec/Presel/GSC/Valid/Var01/Def01/Cnt01/Var02/Def02/Cnt02/Var03/Def03/Cnt03/Var04/Def04/Cnt04/Var05/Def05/Cnt05
aAdd(aRegs,{cPerg,"01","Tabela De ?","","","mv_ch1","C",03,00,00,"G","","mv_par01","","","","","","","","","","","","","","","","","","","","","","","","","HSPSX2","","","",""})
aAdd(aRegs,{cPerg,"02","Tabela Ate ?","","","mv_ch2","C",03,00,00,"G","","mv_par02","","","","","","","","","","","","","","","","","","","","","","","","","HSPSX2","","","",""})
aAdd(aRegs,{cPerg,"03","Extensão Tabelas Bkp","","","mv_ch3","C",03,00,00,"G","","mv_par03","","","","","","","","","","","","","","","","","","","","","","","","","","","","",""})
For i:=1 to Len(aRegs)
If !dbSeek(cPerg+aRegs[i,2])
RecLock("SX1",.T.)
For j:=1 to FCount()
If j <= Len(aRegs[i])
FieldPut(j,aRegs[i,j])
Endif
Next
MsUnlock()
Endif
Next
dbSelectArea(_sAlias)
Return
ANEXO 3: Rotina para execução e controle dos updates modulares
#INCLUDE "PROTHEUS.CH"
#INCLUDE "TBICONN.CH"
/*
FABRICIO AMARO - 06/06/2011
ROTINA PARA REGISTRAR A APLICAÇÃO DOS UPDATES
RESUMO: PARA CADA UPDATE O SISTEMA IRÁ GRAVAR UM ARQUIVO COM O MESMO NOME DO UPDATE MAIS (+) A DATA DO FONTE DESSE UPDATE
SE NA PROXIMA APLICACAO O SISTEMA VERIFICAR QUE A DATA É DIFERENTE, IRA APLICAR NOVAMENTE
OBS.: SE CLICADO EM SIM PARA EXECUTAR O UPDATE, E DEPOIS CANCELAR O UPDATE (ROTINA PADRAO) FICARÁ GRAVADO NESSE LOG QUE ELE JÁ FOI EXECUTADO,
PORTANTO, PARA ESSE CASO, IR NA PASTA DO LOG E APAGAR O ARQUIVO PARA QUE ELE POSSA SER EXECUTADO NOVAMENTE.
*/
User Function MeusUpds()
Private oGera2
p11 := .T.
cLocUpd := "UPDS\" //PASTA NA SYSTEM QUE FICARÁ GUARDADO O LOG DOS UPDATES - SUGESTÃO: CRIE ESSA PASTA
cUpd := SPACE(15)
If p11
cLocSystem := "C:\TOTVS 11\Microsiga\Treinamento\system\" //CAMINHO COMPLETO DA PASTA SYSTEM
cLocSmart := "C:\TOTVS 11\Microsiga\Protheus\bin\smartclient\" //CAMINHO COMPLETO DA PASTA SMARTCLIENT
cTCP := "TCP" //COMUNICAÇÃO TCP COM O SERVIDOR
cAmbiente := "TOTVS_10_PARA_11" //AMBIENTE
cProgCli := "SmartClient.exe" //NOME DO PROGRAMA DO SMARTCLIENT (PROTHEUS10 = TOTVSSMARTCLIENT.EXE | PROTHEUS 11 = SMARTCLIENT.EXE)
Else
cLocSystem := "A:\Protheus10\Treinamento\system\" //CAMINHO COMPLETO DA PASTA SYSTEM
cLocSmart := "A:\Protheus10\bin\smartclient\" //CAMINHO COMPLETO DA PASTA SMARTCLIENT
cTCP := "TCP" //COMUNICAÇÃO TCP COM O SERVIDOR
cAmbiente := "Treinamento" //AMBIENTE
cProgCli := "TotvsSmartClient.exe" //NOME DO PROGRAMA DO SMARTCLIENT (PROTHEUS10 = TOTVSSMARTCLIENT.EXE | PROTHEUS 11 = SMARTCLIENT.EXE)
EndIf
cLog := ""
cLog2 := ""
nCont1 := 0
//VARIAVEIS ESPECIFICAS PARA A PESQUISA DAS FUNÇÕES NO RPO

aType := {}
aFile := {}
aLine := {}
aDate := {}
aTime := {}
//MONTAGEM DA TELA PARA PASSAGEM DOS PARAMETROS

@ 200,1 TO 400,400 DIALOG oGera2 TITLE OemToAnsi("Aplicação dos Updates")
@ 10,018 Say "INFORME AS INICIAIS DO UPDATE - EXEMPLO: UPDCOM | UPDEST" PIXEL OF oGera2
@ 70,018 MSGET oVar VAR cUpd Picture "@!" SIZE 040,10 PIXEL OF oGera2
@ 80,170 BMPBUTTON TYPE 01 ACTION {Close(oGera2)}
Activate Dialog oGera2 Centered
cUpd := Alltrim(cUpd)
IF Alltrim(cUpd) == ""
Alert("Não foi informado nenhum UPDATE!")
Return
EndIf
If MsgBox("Será iniado a execução dos UPDs. Deseja continuar?","Atenção","YESNO")
cNomFunc := "U_"+cUpd+"*" //O * SERVE PRA PESQUISAR O RESTANTE DA STRING
//PESQUISA AS FUNÇÕES NO RPO

aRet := GetFuncArray(cNomFunc, @aType, @aFile, @aLine, @aDate, @aTime)
For nCont := 1 To Len(aRet)

//PRIMEIRO VERIFICA SE ESSE ARQUIVO JÁ EXISTE NA PASTA \SYSTEM\UPDS OU NO CAMINHO ESPECIFICADO
cArqUpd := aRet[nCont] +"_"+ StrTran(dtoc(aDate[nCont]),"/","_")
cArqUpd := cLocSystem + cLocUpd + cArqUpd + ".UPDATE"
cTemArq := FOPEN(cArqUpd)
//SE O ARQUIVO JÁ EXISTIR

If !(cTemArq <= 0)
cLog2 += aRet[nCont] +";"
Else
nCont1++
If MsgBox("Executa "+aRet[nCont]+"?","Atenção","YESNO")
//EXECUTA O SMARTCLIENT COM OS PARAMETROS DO UPDATE
WinExec(cLocSmart+cPROgCli+" -P="+aRet[nCont]+" -C="+cTCP+" -E="+cAmbiente+" -M")
//ARMAZENA O LOG GERAL
cLog += aRet[nCont] +";"
//CRIA NA PASTA SYSTEM O UPDATE PARA DIZER QUE ELE JÁ FOI EXECUTADO
MemoWrite(cArqUpd,cArqUpd)
EndIf
EndIf
Next
cArq := cLocSystem + cLocUpd + cUpd + ".TXT"
MemoWrite(cArq,cLog)
If nCont1 > 0
cMsg := "Compatibilizadores executado com sucesso! Foi gravado os LOG's na pasta SYSTEM"
Else
cMsg := "Não foi executado nenhum compatibilizador!"
EndIf
MsgBox(cMsg,"Acabou","INFO")
If MsgBox("Deseja executar novamente a rotina MeusUpd's?","Meus Upds","YESNO")

U_MEUSUPDS()
EndIf
EndIf
Return

MIT072 Conversao P11 PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

MIT072 Conversao P11 PDF

Enviado por

Direitos autorais:

Formatos disponíveis

MIT072 – Manual de Operação do Protótipo

Conversão/Atualização Release - Protheus Revisão 008 – 29/02/2011

Elaboração: Fabricio Amaro – Unidade TOTVS OP – Bauru – fabricioamaro@totvs.com.br

Colaboração: Gustavo Canela – Unidade TOTVS OP – Bauru – gscanela@totvs.com.br

Victor Nigro – Unidade TOTVS OP – Bauru – jose.vasques@totvs.com.br

Daniel Peixoto da Silva – Unidade TOTVS OP – S. J. Rio Preto – dsilva@totvs.com.br

Marco Smanioto – Unidade TOTVS OP – Bauru – marcosmanioto@totvs.com.br

Evandro Galindo – TOTVS SP – São Paulo – evandro.galindo@totvs.com.br – 12/01/2012

Ederson Guerra – TOTVS OP – Bauru - edersonguerra@totvs.com.br – 23/02/2012

Rodrigo Pedroso – TOTVS OP – Bauru - rppedroso@totvs.com.br – 27/02/2012

Sérgio Passerini – TOTVS OP – Bauru – sergio.passerini@totvs.com.br – 28/02/2012

2) Fazer um backup da pasta Protheus_Data e do banco de dados.

3) Checar a duplicidade de registros:

c. Ajustar os registros duplicados (se houver)

4) Backup e remoção dos índices de usuários - SIX:

5) Apagar todos os arquivos de índices das pastas do Protheus_Data.

6) Apagar os arquivos de LOG e TEMPORÁRIOS

7) Na pasta “SYSTEMLOAD”, exclua os arquivos *.DBF e *.IDX.

a. RPO - Categoria: Repositório de Objetos

b. BUILD - Categoria: Binário TOTVSTec

c. UPDATE - Categoria: Update de Programas

d. PATCH/LIB DE PROGRAMAS - Categoria: Path de Programas

e. HELP - Categoria: Help de Campo/Pergunta

Onde nnn é o limite de licenças que vai consumir do License Server.

13) Arquivo de Senhas.

Na conversão de testes apresentaram erros no arquivo de senhas. A solução é simples:

Dessa forma, a senha do Administrador a ser utilizada será “em branco”.

15) Inicio da conversão.

Porém, tentando novamente, digitei a senha, e passou.

16) Selecione de qual versão será originada a conversão.

a) ValidPerg ou cPerg: tamanho de 6 para 10 - PADR(cPerg,10)

O mesmo só poderá ser apagado se a conversão for iniciada do ZERO.

18) Será apresentada a tela com as empresas que serão convertidas:

19) Ao clicar em AVANÇAR, a conversão terá início.

20) Se houver erros na conversão será apresentada a tela:

Emitir o relatório para analisar os erros. Finalizar a conversão.

O gatilho AK2_CC sequencia 001 esta duplicado

A sugestão é que, antes do início da conversão, seja visto esses problemas.

O do tamanho no SX3 campo EK_NUMOPER é dIferente do SXG

Obs.: EE = Empresa | ext = DBF ou DTC

Obs. 2: os erros de português são do próprio sistema.

24) Arquivo de índices: conforme item 4 desse documento.

A sugestão é que antes do “append” seja feito um backup da SIX principal.

25) Revisão dos índices

26) Novo controle de GRUPO DE EMPRESAS.

Porém, observe que se trata de campos OBRIGATÓRIOS.

29) Folha de Pagamento – Roteiro de cálculo

SUBSTR(RM_SEQ,5,1) <> "0"

b. Após feito o backup, deletar os registros.

30) Verificar os fontes customizados

No Protheus 10, funcionava normalmente a rotina da seguinte forma:

User Function GPE11ROT()

aAdd( aRotinas, { "Oi*" , "u_oi()" , 0 , 6 , , .F. } )

Analise as demais rotinas para saber se estão dessa forma.

Orientações conforme o chamado SCUMUO.

31) Compilar o projeto com as customizações do cliente.

32) Aplicação de UPDATES. (Rev. 005)

Os detalhes da rotina estão no anexo 3.

33) Finalizando: Acessar o SIGAMDI ou ADV, e fazer todos os testes possíveis.

Novo menu: Menu padrão:

B. Folders (pastas) – X3_FOLDER (rev. 007)

Antes da atualização: Após atualização – MP710TO110:

User Function AjFolder()

7) Na pasta “SYSTEMLOAD”, exclua os arquivos .DBF e .IDX.