Hoe los ik een itgenrst013 error op voor datums voor de start van de Gregoriaanse kalender?

Bij het ophalen van data uit een tabel op MySQL om ze te repliceren op SQL Server krijg ik de foutmelding:

itgenrst013: The value '02-06-1064 00:00:00' of the optional column dob in '' is before the start of the Gregorian calendar (01-01-1753 00:00:00)
Ensure that the value is correct in row #30,568. Probably the value should have been null.

Ik krijg daardoor niet alle data binnen uit MySQL.

Hoe kan ik toch deze MySQL tabel repliceren naar SQL Server?

Niet alle databaseplatformen hebben dezelfde randvoorwaarden die ze aan de data stellen. De toegestane waardebereiken kunnen uit elkaar lopen zoals hier voor datums, maar andere scenario’s zijn bijvoorbeeld de semantiek van spaties achter een tekst of het verschil tussen '' en null.

Dit geldt niet alleen voor databaseplatformen. Zelfs cloudplatformen kunnen datakwaliteitissues hebben ondanks dat de API’s als een kwaliteitsschil er om heen zitten. Vooral meer commercieel-gerichte pakketten hebben vaak matige datakwaliteit en beperkte invoercontroles. Bijvoorbeeld custom fields op Teamleader geven vaak problemen door datums met letters of tienduizenden jaren in de toekomst. De financiële pakketten hebben hun zaakjes meestal redelijk op orde. Voorbeelden van problemen daar zijn bijvoorbeeld het aanleveren van een default in plaats van leeg, bijvoorbeeld 0 in plaats van null.

Voor Invantive SQL hebben wel als generieke eis geformuleerd dat een datum moet liggen na het begin van de Gregoriaanse kalender. Dat is die periode waarin de paus besloot een aantal dagen toe te voegen aan de datumregistratie om historische verschuivingen door incorrect jaarlengte te corrigeren (dat gaf een hoop gedoe, vandaar de tegenwoordige schrikkeljaren).

In dit specifieke geval adviseer ik de volgende stappen:

  • Record laten controleren op juistheid door de applicatiebeheerder van het pakket dat op MySQL draait. En indien mogelijk en zinvol laten corrigeren.
  • Uitschakelen controle op datumbereik en vervangen door automatisch schonen.

De tweede stap is een echte noodgreep; het automatisch schonen kan perfect geldige data ook wegpoetsen.

Het wegpoetsen van ongeldige datums stel je in door de Invantive SQL eigenschap invantive-sql-correct-invalid-date op true te zetten (default: false):

Whether to correct dates considered invalid since they are before 01-01-1753. When nullable, they are removed. Otherwise they are replaced by 01-01-1753.

to be added, the command has to be executed from the script, not from the settings.xml
set invantive-sql-correct-invalid-date@dataContainer true

Yes, that is correct. The following settings are actually not attributes of a data container but of the Invantive SQL engine as a whole:

  • invantive-sql-forward-filters-to-data-containers
  • invantive-sql-shuffle-fetch-results-data-containers
  • invantive-sql-correct-invalid-date
  • invantive-use-cache

They can be set from the connection string of a data container, but on the latest BETA this is not correctly forwarded to the actual setting, so you have to set it as said @saudoyna:

set  invantive-sql-correct-invalid-date true

I think this behaviour can be considered a bug. Honesty requires that developers sometimes have deeper and better motivations than I can think of and these might still justify this behaviour).

I haved raised an internal issue ITGEN-5295 for either allowing setting from connection string or some hint to signal that the value is not being used.