Hornbill Request Import v1.2.0 - MySQL driver only importing a single row

[Martyn Houghton]

As first indicated in my earlier post (link below), we are having issues with importing anymore than one request using the Hornbill Request Import v1.2.0. We have been testing with single rows, but now we have got to the stage were we want to test with increasing volume, the utility will only ever retrieve the first row from the RequestQuery table, irrespective of the where clause or even if you do not enter a where clause. The symptoms are as if the SQL is being run with the Limit 1 row setting.

The secondary RequestHistoricUpdateQuery is retrieve successfully all the comment rows for 1 selected request row fine. We have also used the exact same database source for the DB2Hcontactimport v1.2.2 to insert over 3,000 contact records.

Originally we where using a view as the source and I have created a physical table form the view, but the issue occurs for that as well. Environment is MySQL 5.7.24, as I downgraded from MySQL v8 which the tool does not yet support.

Any ideas?

Cheers

Martyn

[Martyn Houghton]

To try workaround this and to determine if the issue lies with the MySQL Driver or Database config, I have migrated a copy of the source table to SQL Server 2017, but the issue still remains that it only returns and processes a single row.

 

So that leaves either the data triggering the behaviour (reserved characters etc) or the tool itself.

Cheers

Martyn

[Steve G]

Hi @Martyn Houghton,

I'm not able to replicate this issue locally with a properly defined configuration, connecting to a MySQL 8.0 data source (as I've been updating the source to work with this - should have a release out in the next couple of days) I'm able to pull and import all records from my test database. Do you have the tool configured to connect to the data source directly, or via ODBC?

It's unlikely to be reserved characters causing the issue, as the driver should still be able to get at those records, and if not then an error would be written to the log during the unmarshalling of the record data.

One scenario which may see this behaviour would be if the tool detects that the request record already exists in memory (as there's code to prevent duplication of imported requests). So if the value of the column defined in the RequestReferenceColumn property is not unique. What do you have defined in your incident import config, as does that match the request reference column in your source data?

Thanks,

Steve

[Martyn Houghton]

@Steve G

Thanks for the pointer on the RequestReferenceColumn property, this was still set to the "h_formattedcallref" field that does not even exist in my data set!

Might be worth putting a check into the code to trap this in the new version, so as to stop anyone else from falling into that one.

Thanks again. 

Now just need to work on the priority matching.

 

Cheers

Martyn