Regression: public stores fail with "SQL logic error" after gromox 3.9.313 update

Public stores fail with "SQL logic error (1)" after upgrading from gromox 3.9.195 to 3.9.313.m3c2f49c-64.1. Public contact and calendar folders can no longer be opened in either grommunio Web or Outlook. The public-store SQLite database is intact and PRAGMA quick_check returns "ok". The regression appears to originate from commit: https://github.com/grommunio/gromox/commit/58f90c7ef87b534708690f7fda46e4a4abc87662 Affected code: exch/exmdb/common_util.cpp, prepared_statements::begin(), around line 414 https://github.com/grommunio/gromox/blob/58f90c7ef87b534708690f7fda46e4a4abc87662/exch/exmdb/common_util.cpp#L414-L417 This statement is prepared unconditionally: msg_read = gx_sql_prep(psqlite, "SELECT read_state FROM messages WHERE message_id=?"); This works for private stores, but the messages table of a public store has no read_state column. Public-store read status is held in the separate read_states table. Preparing the private-store statement while opening a public store therefore fails with an SQLite logic error. exmdb_optimize_stm=off does not help because the statement is prepared unconditionally in prepared_statements::begin(). I tested the following fix successfully: ``` if (exmdb_server::is_private()) { msg_read = gx_sql_prep(psqlite, "SELECT read_state FROM messages WHERE message_id=?"); if (msg_read == nullptr) return false; } ``` After rebuilding and installing Gromox with this change, the existing public contact and calendar folders work again in both grommunio Web and Outlook. No database repair or reimport was required, and no further SQL logic errors appeared.