Atualização do Elipse E3 entre versões distantes.

Pontos de atenção e possíveis quebras de compatibilidade ao migrar de uma versão antiga para uma atual, organizados versão a versão, com validação antes de produção.

1. Introdução

É comum uma aplicação antiga do Elipse E3 precisar migrar para uma versão atual — por fim de suporte, requisitos de sistema ou novos recursos. A dúvida recorrente é: o que precisa ser refeito ou alterado na aplicação?

A regra geral é a retrocompatibilidade: aplicações de versões anteriores continuam funcionando em versões iguais ou superiores. Num salto de várias versões, porém, alguns recursos foram descontinuados ou removidos e outros tiveram o comportamento alterado no caminho. O quadro abaixo organiza esses pontos versão a versão, para que a revisão da aplicação acompanhe exatamente o que mudou em cada etapa.

2. Pontos de atenção por versão

O símbolo ⚠ marca itens que podem quebrar a compatibilidade ou exigir ajuste de código/configuração.

Versão	Pontos de atenção e possíveis quebras
4.7	⚠ A chave de proteção passa a definir o intervalo de versões executáveis (obrigatório em licenças Runtime) — uma chave programada para a 4.6 não é reconhecida pelo E3 4.7 ou superior. ⚠ Mudanças de comportamento em runtime: uma Associação por Tabela passa a atualizar quando a linha é alterada por script (antes não atualizava); e renomear um objeto (ex.: driver de I/O) e aplicar passa a desativar/reativar o objeto no domínio em execução (dispara `OnStartRunning`/reconexão do driver).
4.8	Novos objetos OPC UA (Assinatura / Tag / Bloco) — possibilitam a comunicação de tempo real via OPC UA (cliente). Novo ElipseX `XFolder` e propriedade `EnableTagBehavior` — mudanças no modelo de bibliotecas ElipseX. ⚠ Mudanças de comportamento: o `MouseUp` do E3Browser passa a disparar após a seleção da linha (handlers que leem a linha selecionada veem outra linha); e a escrita de um Viewer-Only em tag de domínio remoto passa a ser bloqueada.
5.0	⚠ Campos de Histórico e Storage viram objetos em coleção (`Fields`), com índices e chaves por objetos: um Histórico salvo na 5.0, por exemplo, não abre nem funciona em versões anteriores. ⚠ Propriedade `Events` renomeada para `ObjectEvents` (quebra scripts). ⚠ `Application.GetObject` passa a validar o caminho inteiro e recusa caminhos que terminam em uma propriedade (não-objeto): `GetObject("obj.Prop")` passa a dar erro. Alinhamento de Tela/Viewer passa a ser controlado por `ScreenAlignment` (default `paTopLeft`, mantido na migração e em novas aplicações). ⚠ Com o descolamento da tela (âncora no canto superior esquerdo), passam a ser renderizados apenas os objetos dentro da área visível da tela. Aplicações que usavam `MoveFrame` para “revelar” objetos fora dessa área ao redimensionar telas janeladas/modais deixam de exibi-los (surge a cor de fundo no lugar). O `MoveFrame` altera o tamanho do quadro, não o da tela: ajuste o tamanho da tela no Studio e abra com zoom 100% sem rolagem (`?100?0`), ou ajuste `Width`/`Height` no evento `OnPreShow`.
5.1	Novo método `LoginWindowsUser` (login silencioso com usuário do Windows).
5.5	Objeto `[?Server]` expõe informações de servidor, clientes, domínios remotos e licença. Arquivamento (Shelve) de alarmes: o operador pode suprimir temporariamente um alarme por um tempo definido (norma ISA 18.2). ⚠ `OpenScreen` sem o argumento de zoom passa a abrir a tela em 100%, em vez de herdar o zoom da tela anterior — aplicações que dependiam dessa herança mudam em silêncio. ⚠ `TypeName` e `IsObject` passam a retornar o valor correto dentro de links/associações — expressões que ramificavam no resultado antigo mudam de comportamento. ⚠ As sessões de Studio e Viewer passam a revalidar periodicamente o usuário logado e a propagar renomeações/invalidações — a sessão de um usuário removido que continuava aberta passa a ser encerrada.
5.6	Grupos de usuários do Windows podem ser cadastrados como grupos do Elipse E3. ⚠ Criptografia AES-128 na comunicação entre E3 Server e clientes — quando habilitada, não é compatível com versões anteriores. ⚠ Tags criadas por `AddObject` em script do Studio passam a respeitar o parâmetro de ativação (antes subiam sempre ativas) — scripts de setup podem encontrá-las inativas.
6.0	Componente TrendAnalysis integrado ao E3. Provedor MSOLEDBSQL torna-se o padrão para SQL Server — garanta que o provider esteja instalado. Aplicações feitas em versões anteriores permanecem com a mesma configuração. ⚠ Mudanças de comportamento: `X`/`Y`/`Width`/`Height` de Grupo e Conector passam a ser lidos já atualizados por script; ActiveX dentro de um Grupo passam a respeitar a visibilidade/camada do grupo (alternar `Visible` do grupo passa a ocultá-los também); e não é mais possível editar um SetPoint desativado.
6.1	Hot-Standby: uma única falha de ping deixa de considerar a rede fora de operação imediatamente (menos comutações desnecessárias). ⚠ Valores inválidos (`NaN`/infinito) passam a comparar como diferentes de um número (antes eram tratados como “iguais”). Como a detecção de mudança de valor sustenta tags, links e alarmes, transições de/para valor inválido que não disparavam `OnValueChange`, propagação de link ou reavaliação de alarme passam a disparar.
6.5	Adicionado suporte nativo a MySQL e PostgreSQL. ⚠ Alarmes ganham a supressão por condição (by design), da norma ISA 18.2 — confira relatórios e consultas sobre a tabela de alarmes. ⚠ Caminhos de objeto com nomes especiais que resolviam sem colchetes passam a falhar (silenciosamente) — use colchetes no caminho do objeto. ⚠ Segurança: ao atualizar aplicações muito antigas (grupos criados antes da 5.6), as referências de grupos passam a ser carregadas — membros podem recuperar permissões de grupo que não estavam sendo aplicadas. Revise as permissões efetivas dos usuários após o upgrade.
6.6	⚠ Relatório de Seção adicionado e o objeto Relatório (antigo) marcado como descontinuado. ⚠ Usuários e grupos do Windows apenas no formato NetBIOS (`DOMINIO\usuario`). ⚠ A persistência do sumário de alarmes passa a respeitar o intervalo mínimo (1 minuto) — aplicações com persistência de sumário habilitada e sem intervalo configurado passam a gravar com frequência diferente (antes o mínimo era ignorado).
6.7	⚠ Não é mais possível inserir Relatórios antigos; o Verificador de Domínio passa a apontá-los como erro. Alarmes: novo estado Out-Of-Service (fora de serviço), da norma ISA 18.2. ⚠ Segurança: o usuário anônimo passa a ser forçado a ser tão ou mais restritivo que seus grupos, e a herança de permissões é recalculada — aplicações com acesso anônimo, ou que dependiam da resolução antiga de permissões, podem perder privilégios em silêncio.
6.8	⚠ Estampas de tempo no SQL Server passam ao tipo `datetime2` por padrão. O provedor antigo `1 - SQLOLEDB` não suporta `datetime2`: após o upgrade, o E3Chart deixa de desenhar as penas históricas e o `E3TimeStamp` pode aparecer zerado (30/12/1999). Correção: alterar o objeto banco de dados para `2 - MSOLEDBSQL` — históricos novos e antigos voltam a funcionar. ⚠ O evento `OnLogout` passa a ocorrer apenas quando o usuário ativo volta a ser o anônimo — aplicações que trocam de usuário via `LoginUser` e tinham lógica no `OnLogout` deixam de executá-la. ⚠ Consultas síncronas do E3Query passam a honrar `CursorType`/`CursorLocation` (antes fixos) — scripts que contavam com o cursor fixo (`RecordCount`, bookmarks, rolagem) recebem um recordset diferente.
6.9	⚠ Objeto E3Playback removido. ⚠ Relatório (antigo) não é mais acessível pelo Studio. Associações passam a aceitar o prefixo `:` para forçar um caminho absoluto (a partir da raiz do projeto). Os novos links já são criados com `:` por padrão; links de aplicações antigas (sem o `:`) continuam válidos e funcionando normalmente. ⚠ Um ActiveX/MSForms sem janela que estava inativo passa a ativar e disparar seus eventos também no clique do botão do meio/direito (antes só no esquerdo) — handlers de `Click` podem executar em cliques antes inertes.

3. Itens que costumam exigir desenvolvimento

Relatórios (formato antigo) → Relatório de Seção

Descontinuados a partir da 6.6, não podem mais ser inseridos desde a 6.7 e não são acessíveis pelo Studio na 6.9 (serão totalmente removidos na 7.0). Não funcionam na versão 64 bits. Migre para o Relatório de Seção antes de concluir a atualização — em uma versão anterior à de destino, onde ainda é possível abrir os dois formatos — e teste cada relatório na versão de destino.

Scripts, propriedades e métodos alterados entre versões

Ao longo das versões, propriedades e métodos foram criados, renomeados ou removidos, e alguns métodos tiveram parâmetros adicionados ou alterados. Por isso, depois de instalar a nova versão, recompile os scripts e rode o Verificador de Domínio para localizar associações e referências inválidas — principalmente as que apontam para propriedades ou métodos removidos ou modificados, como a propriedade ScreenAlignment e a coleção ObjectEvents (antiga Events).

Componentes ActiveX e Microsoft Forms (64 bits)

Independentemente da versão, componentes ActiveX exclusivamente de 32 bits — como o Microsoft Forms 2.0 (FM20.dll) e ActiveX de terceiros — não abrem no Studio 64 bits. Use o Studio de 32 bits (que acompanha a instalação da versão 64 bits) ou instale a versão 64 bits do componente (no caso do Microsoft Forms, o FM20.dll vem com o Office 64 bits). O E3 Viewer é sempre 32 bits.

4. Licença e requisitos de instalação

A chave de proteção (hardkey ou softkey) precisa habilitar a versão de destino (a versão atual desejada) — sem isso, o E3 opera em modo DEMO. A atualização é feita pelo setor comercial, informando o número da licença. Recursos licenciados à parte — como o Servidor OPC UA, o Storage (por quantidade de tags), os Domínios Remotos, Viewers adicionais e os drivers de comunicação — também precisam estar previstos na licença.

Os requisitos de sistema (SO, .NET e WebView2) variam conforme a versão de destino e estão descritos no artigo Requisitos mínimos para instalação do Elipse E3/Power/Water (ver Artigos relacionados). Se o upgrade falhar, feche todos os módulos do E3 e desinstale manualmente os módulos antigos antes de reinstalar.

5. Roteiro de atualização e validação

Não atualize direto em produção. Para ambientes com Hot-Standby, o roteiro recomendado é:

Backup completo dos arquivos da aplicação (arquivo .dom, .prj, .lib, bancos históricos e de alarmes) e tenha em mãos os instaladores Full da versão de destino e da versão anterior.
Coloque o servidor Reserva (Standby) em manutenção pelo E3 Admin (aba Servidores das configurações do Domínio). Ele se dessincroniza do servidor ativo e descarrega a aplicação — parar o Standby diretamente pararia também o servidor ativo.
Reprograme a chave do servidor reserva para a versão de destino e instale a nova versão do E3 (parar a aplicação, fechar todos os módulos, rodar o instalador). O E3 Server irá iniciar automaticamente.
Reavalie as configurações de Firewall e DCOM. Entre versões, módulos do E3 foram renomeados e novos módulos passaram a existir — as exceções de Firewall e as permissões de DCOM precisam contemplar os executáveis da nova versão (use o Elipse DCOM Wizard; ver “Configuração de DCOM e Firewall”).
Tire o servidor de manutenção e aguarde a aplicação voltar ao estado Standby (ícone amarelo no E3 Admin) — não chaveie antes da subida completa.
Execute os testes de sanidade (ver a lista de verificação ao final desta seção). Havendo problema, o servidor ativo (versão antiga) segue como ambiente seguro.
Chaveie manualmente para o servidor atualizado (E3 Admin → Servidor → Ativar).
Atualize todos os Viewers remotos para a versão de destino.
Repita os passos anteriores no outro servidor (o Principal) e, ao final, chaveie de volta para ele — evita um chaveamento automático em horário inesperado.

Sem Hot-Standby

Valide em uma máquina de homologação, sobre uma cópia da aplicação, antes de ir a produção — uma chave de Studio permite executar por até 6 horas para os testes. Só então atualize o servidor de produção, em janela de manutenção.

Configuração de DCOM e Firewall

A comunicação entre servidores E3 (Hot-Standby e domínios remotos) usa o protocolo REC e não depende de DCOM. Já as conexões externas e o OPC clássico (DA) exigem DCOM e Firewall configurados — uma configuração manual. Para isso, utilize o Elipse DCOM Wizard, que ajusta as permissões de DCOM e as exceções de Firewall necessárias (ver Artigos relacionados).

Tenha os instaladores à mão (rollback)

Mantenha o instalador Full da versão de destino e o da versão anterior (mesma arquitetura, x86 ou 64 bits). Como o projeto salvo na versão nova não funciona corretamente em versões anteriores, o retorno é restaurar o backup e, se preciso, reinstalar a versão antiga com esse instalador.

Lista de verificação — itens mínimos antes de entrar em produção

Preparação

Backup completo da versão antiga guardado (arquivo .dom + projetos .prj/.lib + bancos + instalador antigo).
Requisitos de instalação atendidos (ver Artigos relacionados).
Chave habilita para a versão atual desejada e com os recursos licenciados (Storage, Servidor OPC UA, Domínios Remotos, Viewers, drivers).
Janela de manutenção agendada e plano de rollback pronto.

Validação da aplicação (objetos mínimos a testar)

Projeto abre e o Verificador de Domínio não aponta erros pendentes.
Scripts recompilam e executam; alinhamento (ScreenAlignment), Events → ObjectEvents e fontes de IOTag revisados.
Relatórios antigos migrados para Relatório de Seção.
Históricos e Storages gravando e consultando; provider de banco correto instalado (MSOLEDBSQL / ODBC).
Gráficos de tendência (E3Chart) plotando as penas históricas (se não desenharem após o upgrade, configure o provedor MSOLEDBSQL no DBServer).
Servidor de alarmes e Fontes de alarme gerando, reconhecendo e exibindo corretamente.
Funcionalidades gráficas revisadas (objetos de tela, Viewer, ActiveX).
Bibliotecas de usuários (ElipseX) revisadas.
Drivers de comunicação testados (comandos, leituras, versões de DLLs).
Login, senha e permissões validados.

Comunicação e redundância

DCOM e Firewall configurados (Elipse DCOM Wizard) para conexões externas e OPC DA.
OPC UA (cliente/servidor) com certificados e políticas de segurança válidos.
Redundância (Hot-Standby) e domínios remotos testados (comunicação por REC, sem DCOM).
Viewers remotos atualizados para a versão de destino.

6. Observações e boas práticas

Migre por cópia, sempre. O original na versão antiga é o seu rollback.
Não pule a homologação — o risco aparece em tempo de execução, não na instalação.
Para saltos grandes em projetos críticos, migre em etapas: bancada, turno piloto e, então, produção.
Documente os ajustes feitos na homologação para repeti-los em produção.