Hello Michael, Thank you for your response and for pointing that out.
Just to clarify, I am *not* connecting two separate OFBiz instances to the same database or schema. At the moment, I am working with *only a single OFBiz instance (18.12.19)* connected to its own dedicated MySQL databases ( ofbiz, ofbizolap, and ofbiztenant). There is no second OFBiz instance accessing these schemas. Regarding the issue itself, as suggested, I am sharing the relevant error from the logs below. During startup and data loading (--load-data), OFBiz fails while processing demo accounting data. The error consistently occurs when accessing the *PAYMENT* entity, with MySQL reporting that the table does not exist: SQLSyntaxErrorException: Table 'ofbiz.payment' doesn't exist This happens during the CREATE_UPDATE action while loading: applications/datamodel/data/demo/AccountingDemoData.xml It appears that OFBiz attempts to read from the PAYMENT table before it has been created, which causes the transaction rollback and ultimately the startup failure. Environment details: - OFBiz version: 18.12.19 - JDK: 11 - MySQL Connector/J: 9.2.0 - MySQL database engine: InnoDB - Datasource options: check-on-start="true", add-missing-on-start="true" If you have any insight into whether this could be related to: - MySQL connector compatibility with OFBiz 18.12.x - MySQL server version behavior - Known issues with entity creation order for PAYMENT-related entities I would greatly appreciate your guidance. Thank you again for your time and support. Best regards, Ilma Masroor On Fri, Jan 23, 2026 at 6:01 PM Michael Brohl <[email protected]> wrote: > Just in short: you should not connect two separate OFBiz instances to > the same databases and schemas without proper setup. > > See > > https://cwiki.apache.org/confluence/display/OFBIZ/Distributed+Entity+Cache+Clear+%28DCC%29+Mechanism > > For the issue itself, you should provide the logs to see which errors > occured. > > Best regards, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > > Am 23.01.26 um 11:21 schrieb Ilma masroor: > > Hello Jacques, > > > > Thank you very much for the clarification and for sharing your > experience. > > That was really helpful and reassuring to know that multiple OFBiz > > instances can run side by side without conflict. > > > > I am currently working with *OFBiz 18.12.19* and am now trying to connect > > it to a *MySQL database*. I wanted to ask for your guidance, as I am > > running into a persistent issue during startup. > > > > Here is what I have done so far: > > > > - > > > > Added the MySQL JDBC connector (version *9.2.0*) under > > framework/entity/lib > > - > > > > Updated entityengine.xml to map the default, OLAP, and tenant entity > > groups to MySQL datasources > > - > > > > Created three separate MySQL databases: ofbiz, ofbizolap, and > ofbiztenant > > - > > > > Configured the MySQL datasources with the MySQL driver ( > > com.mysql.cj.jdbc.Driver), InnoDB tables, UTF-8 charset, and enabled > > check-on-start and add-missing-on-start > > - > > > > I am running OFBiz with *JDK 11* > > > > Despite this, OFBiz consistently fails during startup while trying to > > create database tables. The failure always occurs on the *PAYMENTS* > table, > > and no tables are created successfully. I have tried multiple clean runs, > > but the issue persists every time. > > > > I wanted to ask: > > > > - > > > > Is there any known issue with MySQL (or newer MySQL connectors) on > OFBiz > > 18.12.19? > > - > > > > Are there specific settings, connector versions, or MySQL server > > versions you would recommend for this OFBiz release? > > - > > > > Is there anything specific about the PAYMENTS entity that could > commonly > > cause this failure? > > > > Any pointers or suggestions would be greatly appreciated. > > > > Thanks again for your time and support. > > > > Best regards, > > Ilma Masroor > > > > On Thu, Jan 22, 2026 at 1:28 AM Jacques Le Roux < > > [email protected]> wrote: > > > >> Le 21/01/2026 à 17:56, Jacques Le Roux a écrit : > >>> For instance using --portoffset 10000 mean that the backend port is > >> actually 10000+8443=10000+8443 > >> > >> For instance using --portoffset 10000 mean that the backend port is > >> actually 10000+8443 > >> > >> Sorry wrong C/P :) > >> > >> >
