Good to know that you have found your problem.
As I said earlier, the design of the IBServices components is confusing when compared with TIBDatabase. However, what you are now pointing to is a naming convention that IBX has picked up from Firebird and dates back to InterBase. That is the "DatabaseName" when used in the Firebird Database API (in IBX TIBDatabase) is really a "Connect String". That is, like a URL it includes the name of the server, the path to the database file, a protocol identifier and even a port no - all in the same string. The Firebird 3 release notes give examples of all the possible combinations.
On the other hand, when used in the Services API, the "DatabaseName" is no more than the path to the database file on the server.
What is happening here is that the Services API connection is to a server rather than a database and the DatabaseName is simply a parameter to a command sent after the connection has been established to the server. It can only be the path to the database file as the server, protocol and port no. are now implicit in the connection over which the command is sent.
The Services API does have its own connect string format. In fact this is almost identical to the Database API, except that the database path is replaced by the string 'service_mgr'. So if
myserver:/var/lib/firebird/data/mydatabase.fdb
is a connect string to a database file on "myserver" for a TCP connection then
myserver:service_mgr
is a connect string to the services API on "myserver" again using TCP.
Of course you don't see this in IBX because the IBServices components hide it from you by having the separate ServerName, Protocol and PortNo properties. Some of the IBServices components (e.g. TValidationService) need to refer to a specific Database (on the server) and so they additionally have a DatabaseName property - but that is the name of a database file on the server - so it is just the path to the database file on the server.
If you think you have now got your head around this, just remember that Firebird 3 has made this even more complicated by adding an "expected_db" parameter to the Services API Params property. And, guess what, the value of this is a path to a database file on the server, but not necessarily the same database as used in the DatabaseName property. - and has nothing to do with the connect string either. This parameter was introduced because of the Firebird 3 capability to have alternative security databases. It tells the server that you are logging in using user credentials in the security database linked to the user database given by the expected_db parameter.
All pretty straightforward really