Prepare a persistent Coordinator DB service ​

Start with a persistent database file, explicit configuration and a tested client connection. Treat the supplied empty-password account as a local example; configure the credentials and network reachability required for the actual service.

The public server workflow supports several applications connecting to one server process. Separate processes must not open the same database file simultaneously. Use independent copies for separate instances rather than interpreting file sharing as replication.

Review request ceilings, connection admission and response sizes against representative work. Inspect effective values through system.settings, and keep server-only admission controls in XML. Changing XML requires a restart; persisted database settings have their own change rules.

Before accepting application writes, create a database copy with VACUUM INTO and test reopening the copy independently. The destination must be absent or empty, and the source must meet the documented copy restrictions. A backup procedure is useful only if its recovery steps are known and tested.

Finally, run authenticated reads and writes through the actual client path, verify expected error handling and confirm diagnostic rotation. Keep secrets out of shared logs and support reports.

See deployment modes, security, request limits and database copies.