Invantive Data Hub runs unattended, so a failure is read afterwards from the output rather than seen on a screen. Two habits make that reading much shorter. ## Read Past `itgencun016` Nearly every failure in a run is reported twice: once wrapped and once in full. The wrapped line looks like ``` Error itgencun016: Error itgencmr406: No provider available to handle requested Get OAuth Token. ``` `itgencun016` is the wrapper and says nothing about the cause. **The code directly after it is the one to look up**, here `itgencmr406`. Searching the forums for `itgencun016` therefore yields little; searching for the inner code yields the answer. ## Reproduce with a Trace Where the message alone is not enough, a trace records what the engine actually did. Three environment variables switch it on: - `INVANTIVE_TRACE_ACTIVE` to `true`; - `INVANTIVE_TRACE_TO_FILE` to `true`; - `INVANTIVE_TRACE_FOLDER` to a folder with a few gigabytes free. A trace file holds the statements, the addresses called and the credentials context, so treat it as confidential and send it to support rather than posting it. Send the file whose name ends in `-c`: that is the closed form, written when the run ended, and it holds the whole run including the reason it stopped. A file still ending in `-writing` belongs to a run that is either still busy or was killed. The file of `/logfile` deserves the same care from release 27.0 onward. It used to hold the messages of the run alone, and now holds the results of the statements as well, on lines carrying the channel `STDOUT`, so it can contain business data. `/results:false` keeps them out of it; see [[Invantive Data Hub/Command Line Options|Command Line Options]]. ## Logging On Fails - `itgenuty726`: the catch-all for a connection which could not be established. The line under it names the real reason, often a time-out or a `System.Net.WebException`. - `itgencmr406`: no provider is available to handle the OAuth token request. The message lists the data containers which were opened, and the one expected to serve the token is missing from that list. - `itgeneuy106`, `itgenobr113`, `itgenobr344`, `itgenoda494`: authentication against Exact Online. `itgenoda494` is the clearest of them: a refresh token which has been superseded cannot be used, which happens when one Exact Online user is coupled twice to the same OAuth app. Several of these were defects which a later release closed; re-authentication after an upgrade to release 26.0 is one such case, corrected in 26.0.167. Check the release in the banner against the current release before investigating further. An unattended run cannot answer a question. Where the licence or the agreement is missing, the product opens its menu, reports `itgencmm002` because nothing answers, and ends with `itgenlic681` and [[Invantive Data Hub/Exit Code|exit code]] 7. Run it once by hand on that device; see [[Invantive Data Hub/Configuration|Configuration]]. ## The Program Does Not Start - `itgencuy002` with exit code 9: the `appsettings` file of the environment is missing. - `itgeneay003`: that file exists but its `DataHub` section did not bind. - `itgendhb002` with exit code 5: a command line argument is in an invalid format. Arguments take a slash and a colon; see [[Invantive Data Hub/Command Line Options|Command Line Options]]. - `itgendhb297` with exit code 5: the command line carries a script file as well as one or more statements, while only one of the two can be the source of the run. Available from release 27.0. - `itgendhb298` with exit code 5: `/statement` was given without the statement it was to carry, for instance as the last argument of the command line. Available from release 27.0. - `itgendir105`: the installation is incomplete, usually a download which was broken off. ## A Statement Fails Against the Platform The platform decides what it accepts, and its refusal is passed through unchanged. `itgenoda059` is typical: Exact Online refuses a quantity with decimals on an item which is not divisible, and returns `500 Internal Server Error` with a message whose placeholders it did not fill in. Two things help there. The system messages on Invantive Cloud record the last natural key of the failing row, which usually contains the API address including the identification of the record, so the row can be found. And a `synchronize` statement reports the context it was working on in `itgendhb173` just before the failure, which names the statement and the target table.