Connx Sync taking longer than expected

Product/components used and version/fix level:

ConnX version 14.8

Detailed explanation of the problem:

when perform a sync of table from testDatabase ( Source Enterprise OLEDB/ODBC Adapter to Target SQL Server), which contains 9000 rows, it takes more than 20 mins (on an average).

Error messages / full error message screenshot / log file:

below is snipped of connx web interface DatSync > ‘Historocal Syncs’ tab

Question related to a free trial, or to a production (customer) instance?

What are the factors effecting duration of sync?
How can I improve the sync duration?

The slow performance may be due to the source ODBC driver for IDMS.
Could you please use Infonaut, and issue a “SELECT * FROM ” for the table in question, and report how long it takes to return the 9000 rows. This will give us a baseline of how quickly IDMS returns the data to CONNX.

Hello Larry,

Run a query on InfoNaut.
query: Select * from {database}.dbo.{table}
Records 1 of 9017 || Records/Sec : 59 || Time : 152.3484526

  • it took 2-3 mins to view all the rows in that tables
  • the table contains 9017 rows
  • in the above message the sync that shows 9016 is the same table as here

Run a DataSync using transformations.
Transformation Name || Target Table || Start || End || Rows || Inserted || Updated || Deleted || Sync Type || Status Code
NewTransformation || SQLServerTable|| 5/22/2024 8:22:12 AM || 5/22/2024 8:22:17 AM || 0 || 0 || 0 || 0 || Full (NoCRC) || Success

  • No new transformation just load the all the columns to a new custom column.
  • Not sure why Rows, Inserted, Updated, Deleted are 0.
  • time taken in only 5 secs
  • And I can see all the 9016 rows on the newly create SQLserverTable

Run a DataSync Tables.
Item Name || Catalog || Owner || Start || End || Rows || Inserted || Updated || Deleted || Sync Type || Status Code
TableName || MainframeDatabase || dbo || 5/22/2024 8:23:10 AM || 5/22/2024 8:25:45 AM || 9017 || 0 || 0 || 0 || Full || Success

  • it took 2-3 mins to complete the sync to [mainframeDatabase].[TableName]
  • [mainframeDatabase].[TableName] Already exsisting from previous syncs

On InfoNaut
it says 9017 rows are available to view

On a newly created Transformation to a new table.
select count(*) from [dbo].[SQLServerTable] - 9016 rows

On sync table
select count(*) from [mainframeDatabase].[TableName] - 9017 rows

Running Sync on server took 2-3 mins to complete sync (Full Reload) to SQLServer

II notice that these times are much different than what was originally reported - were you syncing this table in a group when you had the slower times?

No,

we want to sync all the tables in a group, but we are syncing one table at a time.

I just ran a sync of 1 table from tables tabs (/datasync/tables) and took 20 mins to complete the Sync

2024-05-23 08:42:45 AM	00:20:24	9017	0	0	0

In your prior message you stated that the sync took 2-3 minutes, and now you are stating it takes 20 minutes. Is my understanding correct?

There are 2 places I performed sync and posted results

  1. from connx server machine using connx dataSync classic application
  2. using connx web interface, run from developer machine, using port {ip-address-of connx server}:9500

The issue is with running sync on web interface.

“Could you please use Infonaut, and issue a “SELECT * FROM ” for the table in question, and report how long it takes to return the 9000 rows” -

from connx application running from server,
using connx datasync classic application -32bit, it took only 2-3 mins
(as i am unable to share snippet from the connx installed machine, I noted down the numbers)

"II notice that these times are much different than what was originally reported " -

  • the initially reported numbers are issue from connx web interface.

but when running the sync from connx web interface,
https:/{ip address of the server}:9500/ , it took 20 mins.
(snippet took from developer machine, using connx web interface)

Thank you for providing this additional detail.

With this information, it will be necessary for you to create a support incident so this issue can be researched further. The performance of the web interface should be identical to that of the classic interface.