A TOTVS está guerreira na liberação de releases do Protheus 10, já está na terceira. Isto mostra o empenho da empresa em melhorar continuamente o produto.  Entretanto, lançamentos de releases têm seu custo, mais do que financeiro, de exposição a falhas do produto.

Comecei a fazer os testes para a virada de versão do Protheus 8.11 para o 10.1, release 1.2, e já havia identificado e solucionado os problemas que teria no momento de migrar o ambiente de produção para a nova versão.

Ontem, comecei a refazer os testes de migração, de modo a garantir que a documentção que preparei esteja correta, e que eu consiga fazer a virada de versão em poucas horas.

Tudo ocorria como planejado, eu ia seguindo o roteiro que escrevi, os problemas ocorriam nos pontos que eu havia identificado e as soluções que eu havia criado realmente funcionavam, entretanto, já em um momento adiantado da migração, me deparei com um erro de criação de índices.

A primeira falha ocorre no índice ADE010 ordem 5, ou ADE0105, que tenta concatenar dados de tipos diferentes, um campo tipo caracter a um campo tipo data o que, como quem trabalha na área sabe, não é possível, ao menos sem o uso de uma função para “IGUALAR” os tipos.

Mesmo sem consultar a TOTVS, coloquei a tal função para igualar os tipos e, ao rodar o processo de migração, consegui passar por esse ponto, mas parei num dos próximos passos.

A chave ADE010F, ordem 15 do ADE010, apresentava o mesmo problema, dois campos tipo data sem tratamento sendo concatenados a campos tipo caracter. 

Embora eu tenha tentado usar a mesma solução que usei no erro anterior, transformando o campo tipo data em tipo caracter, o sistema continua apresentando o mesmo erro crítico, e não consegue criar o índice.

Minha suspeita é que a string que descreve a chave do índice esteja muito grande (realmente o é) e o PROTHEUS a esteja trucando, gerando o problema.

Entrei em contato com o suporte da TOTVS e fui imediatamente atendido, o atendente acompanhou minhas observações, confirmou o problema e encaminhou para solulção.

Por hora, para continuar com meus testes, simplesmente excluí a chave de índice que apresentava problema, no SX1010, índice ADE ordem F, o que garantiu que completasse a atualização, mesmo porque o arquivo ADE010 é novo, e não fundamental neste instante.

Me chamou a atencção a quantidade de índices definidos para essa tabela. São 20 índices, número muito alto para a minha escola de desenvolvimento. 

Agora, vou esperar a resposta ao problema detectado, sem atrasar os testes.

Dúvidas, críticas, sugestões ? Deixe seu comentário.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Pois é, continuo trabalhando na virada de versão do Protheus 8.11 para o Protheus 10.1 e, ao mesmo tempo, do “banco de de dados” DBF (codebase) para um BANCO DE DADOS MS SQL.
Com já havia sido alertado, estou sofrendo com chaves duplicadas.
Acontece que o Microsiga baseado em CODEBASE não faz consistências sobre chaves primárias duplicadas, exceto se você o fizer via função no validador do campo.
Como minha base de dados vem dos tempos da versão 2.Alguma coisa, inúmeros registros se encontram duplicados.
Estou desenvolvendo funções paralelas para sanar mais este problema.
Continuarei informando.
Dúvidas, críticas, sugestões ? Deixe seu comentário.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Como tenho postado, estou fazendo os testes para a virada de versão do Microsiga Protheus.
Até hoje, minha opção foi utilizar o Protheus sobre base de dados CODEBASE, nosso velho DBF, pois nosso volume de dados e quantidade de usuários não tornava imperativo o uso de SGBD´s como SQL Server. Além das outras desculpas como falta de tempo para me dedicar ao processo de migração de base de dados.
Agora resolvi me livrar de vez desse passado, virando a versão do sistema, do meu atual Microsiga Protheus 8.11 para o Microsiga Protheus 10.1 e, ao mesmo tempo, migrando a base de dados para o padrão SQL.
Até mesmo por falta de qualidade nas migrações anteriores, uma vez que o ERP da Microsiga está em uso aqui há mais de 12 anos, também achei interessante “passar um pente fino” no atual processo de virada de versão analisando, praticamente, registro por registro em cada tabela.
Por hora, os principais problemas com os quais me deparei foram as diferenças entre o dicionário de dados oficial da versão atual, 10.1, com o meu dicionário de dados.
Campos com tamanho diferente, campos inexistentes e campos obsoletos foram os maiores obstáculos que encontrei enquanto comparava o dicionário de dados correto (considero o dicionário de dados oficial – que pode ser baixado do site da microsiga – como correto) e o meu dicionário de dados e estruturas das minhas tabelas.
Também encontrei um campo do tipo DATA, no dicionário de dados da Microsiga, definido com o tamanho 11, quando o correto é 8.
Um passo básico nas viradas de versão da microsiga é a execução do aplicativo de UPDATE, no meu caso o MP710TO101, entretanto, essa rotina de atualização não corrige diversos erros que ela encontra pelo caminho, por considerá-los personalizados demais para correção automática, posição com a qual concordo plenamente. Por isso, precisei criar o meu próprio aplicativo de correção desses erros.
Em resumo, esse aplicativo que criei verifica os campos de minha base de dados que estão obsoletos, verifica se há conteúdo nesses campos e, caso negativo, remove-os. Ele cria os campos do dicionário que, por qualquer motivo, não existiam em minhas tabelas e ajusta o tamanho dos campos, na tabela ou no dicionário de dados, sempre mantendo o maior tamanho para evitar perda de dados.
Após executar esse utilitário (o que leva algumas horas), o programa de UPDATE da Microsiga pôde ser aplicado, fazendo os ajustes finais e liberando a nova versão para uso.
Na hora de migrar o banco de dados, de DBF para MS SQL, deparei-me com alguns (muitos) registros que geravam erro no momento da importação pelo APSDU.
Tratavam-se de campos cujo valor, nem era NULO, nem ESPAÇOS em branco, nem qualquer conteúdo visível.
Consegui identificar que esses campos estavam preenchidos com uma sequencia de caracteres NULOS e ESPAÇOS EM BRANCO, o que gerava conflito com a cláusula NOT NULL do SQL. Tive que fazer outro aplicativo para varrer minha base de dados e corrigir o problema.
Agora, estou finalizando a importação da base de dados para o MS SQL EXPRESS, para verificar como minhas funções customizadas se comportarão nesse novo ambiente.
Dúvidas, críticas, sugestões ? Deixe seu comentário.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Se você não conhece o sistema MICROSIGA PROTHEUS, talvez o título deste post não lhe diga muita coisa, entretanto, para desenvolvedores desse poderoso ERP, já é possível entender que há algo errado.
Acontece que um dos fundamentos da programação em linguagem ADVPL é que todas as funções começadas com U_ são reservadas para customização, ou seja, nunca poderiam estar presentes no núcleo original do sistema, mas estão.
Estou preparando a virada da versão 8.11 para a 10.1 e, ao compilar minhas customizações, me deparei com uma mensagem de duplicidade na função geradora de duplicatas, USER FUNCTION DUPLI().
Entrei em contato com o atendimento ADVPL e a atendente me explicou que, provavelmente, trata-se de uma função EXEMPLO, que pode ter sido compilada junto ao repositório disponível para download.
O que eu achei mais estranho é que a atendente me disse que tal funcão, hora pode estar compilada junto ao RPO, hora pode não estar.
Enfim, para evitar maiores problemas, decidi que mudarei o nome da minha função.
Mas, mesmo assim, fica a pergunta: Como podemos confiar em um padrão (criado pela própria Microsiga) que diz que todas as funções U_ são de uso livre em customização se, quando vou compilar minhas funções, descubro que já existe uma função com o nome que escolhi ?
Pesquisando esse assunto, descobri que a atual versão do RPO contém muitas funções iniciadas com U_, por exemplo: U_ABSENT (extremamente fácil haver cusmtomizações usando este nome), no programa ABSENT.PRX, U_AC060DLB (AC060DLB.PRW), U_AC70DECL (AC70DECL.PRW) e, pelo menos, mais 6 outras.
Minha dica, neste caso, é que você renomeie as funções que gerarem conflito. Não vale a pena perder muito tempo discutindo o assunto com a Microsiga (você terá que renomear todas as chamadas de menus e programas para a função).
Agora, se você achar que terá muito trabalho para renomear as funções, não tenha dúvidas, entre em contato com eles e solicite que o RPO seja compilado sem essas funções.
Dúvidas, críticas, sugestões ? Deixe seu comentário.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.