Issue During Migration of Schedulix Database to MySQL 8.4

[guadalinfo...@gmail.com]

Hello,

We are currently in the process of migrating the database for our Schedulix system. At present, we are using MySQL version 5.7 with Schedulix 2.9, and we have attempted to change the Schedulix connection to use the new database running MySQL 8.4.

To do this, we set up MySQL 8.4 as a replica of the MySQL 5.7 version, and initially, synchronization was working without issues.

Yesterday, we made the switch and pointed Schedulix 2.9 to the new MySQL 8.4 (replication was stopped beforehand, of course). During the startup process, the Schedulix server threw the following errors:

ERROR   [Thread-1]      30 Jul 2025 17:01:41 GMT Duplicate id during load Object

ERROR   [Thread-1]      30 Jul 2025 17:01:41 GMT ****************** Start Stacktrace *********************ERROR   [Thread-0]    30 Jul 2025 17:01:41 GMT Duplicate id during load Object

ERROR   [Thread-0]      30 Jul 2025 17:01:41 GMT ****************** Start Stacktrace *********************

ERROR   [Thread-0]      30 Jul 2025 17:01:41 GMT de.independit.scheduler.server.util.SDMSThread.doTrace(SDMSThread.java:168)ERROR   [Thread-0]  30 Jul 2025 17:01:41 GMT de.independit.scheduler.server.exception.FatalException.<init>(FatalException.java:50)

ERROR   [Thread-0]      30 Jul 2025 17:01:41 GMT de.independit.scheduler.server.repository.SDMSTable.loadObject(SDMSTable.java:194)

ERROR   [Thread-0]      30 Jul 2025 17:01:41 GMT de.independit.scheduler.server.repository.SDMSResourceRequirementTableGeneric.loadTable(SDMSResourceRequirementTableGeneric.java:323)

ERROR   [Thread-0]      30 Jul 2025 17:01:41 GMT de.independit.scheduler.server.repository.TableLoader.SDMSrun(SDMSRepository.java:430)

ERROR   [Thread-0]      30 Jul 2025 17:01:41 GMT de.independit.scheduler.server.util.SDMSThread.run(SDMSThread.java:225)

FATAL   [main]          30 Jul 2025 17:01:41 GMT Fatal exception while loading Repository:

Duplicate id during load Object

FATAL   [main]          30 Jul 2025 17:01:41 GMT ****************** Start Stacktrace *********************

FATAL   [main]          30 Jul 2025 17:01:41 GMT de.independit.scheduler.server.util.SDMSThread.doTrace(SDMSThread.java:168)

FATAL   [main]          30 Jul 2025 17:01:41 GMT de.independit.scheduler.server.Server.serverMain(Server.java:469)

FATAL   [main]          30 Jul 2025 17:01:41 GMT de.independit.scheduler.BICServer.main(BICServer.java:144)

FATAL   [main]          30 Jul 2025 17:01:41 GMT ****************** End Stacktrace   *********************

[scrolllog] Waiting for child (514) to terminate

[scrolllog] Child exited with state 1

[scrolllog] Try to restart child (child terminated with exit code <> 0)

We reviewed the RESOURCE_REQUIREMENT table (ERROR [Thread-0] 30 Jul 2025 17:01:41 GMT de.independit.scheduler.server.repository.SDMSResourceRequirementTableGeneric.loadTable(SDMSResourceRequirementTableGeneric.java:323)), and we do see duplicate values. However, the original MySQL 5.7 database also contains duplicate IDs, and Schedulix starts up without any issues (we’ve attached a screenshot of the values in the original table).

Could you help us understand what might be happening? Do we need to consider a different approach for this database migration?

Thank you for your assistance.

[Dieter Stubler]

Hello,

The resource_requirement table is versioned, so to check for duplicates you have to check for overlapping valid_from and valid_to for same id.
Is it possible you did loose the valid_from/valid_to during mirgration of the data?

Regards
Dieter

[guadalinfo...@gmail.com]

Hello Dieter,

Thank you for your prompt response.

We have reviewed the data using the filters you suggested, and indeed, we have identified duplicate values (please find attached an image showing the search results).

What would be the implications if we were to delete some rows or modify values to ensure uniqueness? Could this impact system functionality or data integrity in any way?

Kind regards

[Dieter Stubler]

Hi,

looks like for some reason some rows have been duplicated during migration/synchronization/replication of the repository database to MySQL 8.4

Since there obviously is at least one flaw in replicating the repository, I would strongly recommend to check and retest the migration procedure and make sure that both are identically before switching.

If this is a non production critical server a quick solution might also be to check whether those duplicate rows are identically over all columns (what I expect to be)
and remove the duplicates if so. If this was the only inconsistency introduced by migrating the repository your server may startup and work fine again.

Regards
Dieter

[guadalinfo...@gmail.com]

Thank you Dieter...

We go to review the migration process and ensure that the database replication or import is identical to the source.