Product Suggestion - If DBF is defined in the connection string but there is already a running Server and Database that matches the calculated names from the DBF path AND the running Database has a different path than the DBF the command should throw an error.
For example, if I have a database already running with the following startup parms:
-xTCPIP(Port=2638) -nExample D:\Databases\db\example.db -nExample
And I then want to validate that a backup of that database is valid by using the following command:
dbvalid.exe -c "DBF=E:\Backups\Example\example.db;uid=validator;pwd=validator"
DBValid will actually connect to the already running Database (located at D:\Databases\db\example.db instead of the actual database file I specified in the connection parameter.
Refer to dbvalid valid giving different errors? for an example of where this would've been really useful.
Background: Since your connection string does not specify a server name nor a database name the client attempts to derive this information from what it does have - it uses the DBF parameter to determine that you want to connect to the database named "example" on the "default" server. Since there is a server (running on the local computer) that has a database named "example" (note case insensitive comparisons) then it connects to that database.
To address your suggestion: I'm not sure that this request is feasible. Some thought experiments would need to be done first. For example, what if the database was started using simply "example.db" and the client specified dbf=somepath\example.db then (if this feature was implemented) should the connection succeed or fail? Hmmm, we don't know for sure purely based on the pathnames. We would need to use some other method (e.g. inode check) to make the determination.
Now what should happen in the case when the client(s) have been deployed and the system admin (DBA) needs to move the database to a new location - e.g. to a larger disk or a new computer - and the pathname to the database changes. If the clients used DBF=path\dbname.db to connect to the database then suddenly the connections would fail.
And then there is the issue of backward compatibility!
So the short answer is that you should always be sure to specify the server and the (logical) database name to which you want to connect to ensure that you are connecting to the correct server and database. This recommendation is made several times in the documentation - e.g. in the Remarks section for DBF
... but thank you for your suggestion. The SA development team will need to consider this further and perhaps some change can be made in a future release to address this issue?
In the meantime, I would recommend using Graeme's suggestion (adding DBN=SomeOtherDBName) or adding ServerName=MyValidationServer (or some other random name).
Another suggestion would be to always use -xd (do not become default server) on ALL of your server command lines to ensure that there is not a default server running on the computer - doing so will ensure that you do not connect to the wrong database server (presuming you are controlling all of the server start lines on the computer & no OEM apps have been installed that use SA which have not specified -xd) - i.e. it will force you (and all apps) to always specify the server name in the client connection string ... Which BTW is why we recommend to OEMs (and any application developer that is going to deploy their software into unknown/uncontrolled situations) to also always use -xd and to specify the server name in their applications.