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).

Als dat niet zo is, dan treedt een itgenrst011 of itgenrst013 op. De itgenrst011 treedt op indien het veld verplicht een waarde heeft en itgenrst013 bij een optioneel veld.

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

1 like

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 @sda:

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.

What is the exact process to set the correct invalid date to true ?

Where should this be done and how?

Ideally, you best correct the data failures directly in Teamleader. In the error pop-up you will see some context like the name of a company or title of a deal. On Power BI, this is visible in the Bridge Online Monitoring on https://bridge-online.cloud and in System Messages.

Find this company, deal or whatever entity concerned in the Teamleader web user interface. Check the values of the custom fields and correct them in the Teamleader user interface.

I understand but as explained it is not possible to do this as this field can be left blank, when it it left blank it gives this error. There is no possibility in Teamleader to set a default for custom fields

The value does not have to be corrected everywhere, nor do default values have to be set.

Typically there are a just few records with custom fields with invalid values such as a date before 1753 or a number with ‘A’ in it. The records to be corrected can be found by inspecting the error message in the error pop-up or for Bridge Online in Monitoring.