Can Live Code or Hot Reload support zero-downtime updates for a Delphi service that accesses a database?

Short answer

Live Code can, under narrow conditions, patch method bodies in a running Delphi service — including database-access code — without a process restart. Hot Reload cannot help you at all: it targets VCL/FMX GUI applications that run a Windows message loop, which a service does not have. Neither feature, however, gives you true zero-downtime deployment in the production sense.

What is confirmed vs. what is likely

Confirmed by the documented design: Hot Reload requires a debug-mode desktop application with a UI message loop. A Windows service has no message loop, so Hot Reload simply never triggers — enabling it has no effect, and any code change still requires a service restart. This answers your second question directly: no, Hot Reload does not support non-UI modules in a service.

Likely, based on documented Live Code behavior: Live Code works when the process runs under the RAD Studio debugger with Live Code enabled and the binary is compiled with debug information. It patches method bodies only. It cannot change class declarations, field layouts, or interfaces, and it cannot safely update objects that are already instantiated. For a service, that means attaching the debugger to the running service process — which is a debugging scenario, not a production update mechanism.

What this means for your database code

Changing a SQL string, adjusting a parameter, or tweaking business logic inside a method body is the kind of edit Live Code can apply. Changes that alter class structure, add fields, or touch code currently executing inside an open transaction will be rejected by the IDE or leave the service inconsistent. Applying a patch mid-transaction risks partial updates, so the service should be quiesced first — which already contradicts "zero downtime."

Verification steps for your case

1. Build the service in a debug configuration with debug info enabled; install and start it.
2. In RAD Studio (11 or newer), enable Live Code under Tools → Options → Debugger → Live Code, then attach the debugger to the service process.
3. Set a breakpoint in a method that runs a SQL Server query.
4. While halted, edit the method body (for example, modify the SQL text), apply the Live Code change, resume, and confirm subsequent calls use the new logic without a restart.

If the IDE rejects the patch, the edit touched something outside a method body — that is your boundary.

Recommendation

Treat Live Code as a debugging aid for a staging service, not as an update pipeline. For genuine zero-downtime migration of a production Windows service against SQL Server, use an operational pattern instead: run two service instances behind a failover mechanism, drain connections on one, update it, verify, then switch traffic back. Database schema changes should be made backward-compatible (additive columns, versioned stored procedures) so old and new binaries can coexist during the switchover.

One detail that would change this recommendation: whether your service hosts any listener (HTTP, named pipes, MSMQ) that can be drained gracefully. If it does, the two-instance approach is straightforward; if it polls the database directly, you will need a lease/locking table so only one instance processes work during the cutover.