Ao usar SQL padrão ou a camada de objetos no InterSystems IRIS, a consistência dos metadados é geralmente mantida por meio de validação integrada e imposição de tipo. No entanto, sistemas legados que ignoram essas camadas—acessando globals diretamente—podem introduzir inconsistências sutis e graves.

Compreender como os drivers se comportam nesses casos extremos é crucial para diagnosticar problemas de dados legados e garantir a confiabilidade da aplicação.

O banco de dados DATATYPE_SAMPLE foi projetado para ajudar a analisar cenários de erro onde os valores das colunas não estão em conformidade com os tipos de dados ou restrições definidas nos metadados. O objetivo é avaliar como o InterSystems IRIS e seus drivers (JDBC, ODBC, .NET) e diferentes ferramentas se comportam quando tais inconsistências ocorrem. Nesta publicação, focarei no driver JDBC.

Qual é o Problema?

Algumas aplicações legadas escrevem diretamente em globals. Se um modelo relacional (criado via CREATE TABLEou definido manualmente usando um mapeamento de global) for usado para expor esses dados, o mapeamento define que os valores subjacentes estão em conformidade com os metadados declarados para cada coluna.

Quando essa suposição é quebrada, diferentes tipos de problemas podem ocorrer:

1. Falha de Acesso (Access Failure): Um valor não pode ser lido de forma alguma, e uma exceção é lançada quando o driver tenta acessá-lo.
2. Corrupção Silenciosa (Silent Corruption): O valor é lido com sucesso, mas não corresponde aos metadados esperados.
3. Mutação Não Detectada (Undetected Mutation): O valor é lido e parece válido, mas foi silenciosamente alterado pelo driver para se ajustar aos metadados, tornando a inconsistência difícil de detectar.

Simulando o Comportamento

Para demonstrar esses cenários, criei o banco de dados DATATYPE_SAMPLEdisponível no InterSystems Open Exchange:
🔗 Package page
🔗 GitHub repo

A tabela usada para a demonstração:

CREATE TABLE SQLUser.Employee (
   ID              BIGINT          NOT NULL AUTO_INCREMENT,
   Age             INTEGER,
   Company         BIGINT,
   DOB             DATE,
   FavoriteColors  VARCHAR(4096),
   Name            VARCHAR(50)     NOT NULL,
   Notes           LONGVARCHAR,
   Picture         LONGVARBINARY,
   SSN             VARCHAR(50)     NOT NULL,
   Salary          INTEGER,
   Spouse          BIGINT,
   Title           VARCHAR(50),
   Home_City       VARCHAR(80),
   Home_State      VARCHAR(2),
   Home_Street     VARCHAR(80),
   Home_Zip        VARCHAR(5),
   Office_City     VARCHAR(80),
   Office_State    VARCHAR(2),
   Office_Street   VARCHAR(80),
   Office_Zip      VARCHAR(5)
);

Exemplo 1: Falha de Acesso

Para simular uma inconsistência, injetei valores inválidos na coluna DOB(Date of Birth / Tipo de Dado DATE) usando acesso direto ao global. Especificamente, as linhas com chaves primárias 101, 180, 181, 182, 183, 184 e 185 foram preenchidas com valores que não representam datas válidas.

Os valores agora se parecem com isto:
 
Como você pode ver, uma string foi anexada ao final de um valor $H (Horolog). De acordo com os metadados da tabela, esta coluna deveria conter uma data—mas o valor armazenado claramente não é uma.

Então, o que acontece quando você tenta ler esses dados? Bem, isso depende da ferramenta que você está usando. Testei algumas ferramentas diferentes para comparar como elas lidam com esse tipo de inconsistência.

1) SquirrelSQL (SQuirreL SQL Client Home Page)

Quando o SquirrelSQL tenta acessar os dados, ocorre um erro. Ele tenta ler todas as linhas e colunas, e qualquer célula que contenha dados inválidos é simplesmente marcada como "ERROR". Infelizmente, não consegui encontrar quaisquer detalhes ou mensagens de erro adicionais explicando a causa.

2) SQLWorkbench/J (SQL Workbench/J -  Home)

O SQL Workbench/J para de processar o conjunto de resultados assim que encontra a primeira célula inválida. Ele exibe uma mensagem de erro como "Invalid date" (Data inválida), mas infelizmente, não fornece nenhuma informação sobre qual linha causou o problema.

 
3) DBVisualizer (dbvis) &  DBeaver (dbeaver)

O DBVisualizer e o DBeaver se comportam de forma semelhante. Ambas as ferramentas continuam lendo o conjunto de resultados e fornecem mensagens de erro detalhadas para cada célula afetada. Isso torna fácil identificar a linha correspondente que causou o problema.

4) SQL DATA LENS (SQL Data Lens - a powerful tool for InterSystems IRIS and Caché)

Com o lançamento mais recente do SQL DATA LENS, você obtém informações detalhadas sobre o erro, a linha afetada e o valor real do banco de dados. Conforme mostrado na captura de tela, o valor interno para a primeira linha na coluna DOB é "39146<Ruined>", que não pode ser convertido em um DATE válido.

O SQL DATA LENS também permite configurar se o processamento do resultado deve parar na primeira célula errônea ou continuar a leitura para recuperar todos os dados disponíveis.
 

A próxima parte deste artigo mostrará detalhes sobre:

Corrupção Silenciosa: O valor é lido com sucesso, mas não corresponde aos metadados esperados.

Mutação Não Detectada: O valor é lido e parece válido, mas foi silenciosamente alterado pelo driver para se ajustar aos metadados, tornando a inconsistência difícil de detectar.

Andreas