(Yes, this is a rhetorical question... - Nevertheless, I'm gonna ask it here in an attempt to not forget about this seeming trivia.)
By embedded, I mean an application with a local database, and ENG is the classical connection parameter to specify the local database engine - whereas v12 prefers the SERVER parameter over the now deprecated ENG...
Yes, you should specify this always - that is for each and every connection of your application - otherwise you might end up like me:
The story behind this question: We have used a SQL Remote setup for more than a decade as part of an application set. In the first time, we have called DBRemote.exe directly, but later switched to use the DBTools API to call the DBRemoteSQL() function, so the progress messages can be shown within the application itself. All fine - unless users restore old databases from backups and break replication that way....
In very rare cases, however, the replication didn't work, since DBRemoteSQL() couldn't start the database. This was unepxected, as the database is already loaded when the API is called. Very strange, happened only two or three times in all those years but was reproducable then. Interestingly enough, calling DBRemote.exe once with the same parameters has worked in those cases, and usually, then the problem went away. - I have considered this one of those cases where you decide "You don't need to understand each mystery" and go on.
Yesterday, the same happened again on a customer machine, reproducable with remote control, and the explicit DBRemote.exe call worked. But this time the API call still wouldn't work, and - let's say based on some undeserved intuition - I checked the running processes and found a running dbsrv9.exe. That led to the solution: I stopped that database engine, and then our replication worked again as usual. (BTW: It was a Lexware product that has installed the dbsrv9.exe).
So I checked back the code and found out that when starting our application, we surely do use both ENG and DBN parameters (from an ODBC DSN), however, when preparing the API call, only the DBN (and credentials) was specified, whereas the ENG parameter was missing.
Apparently, that made DBRemoteSQL() try to start the database file on the default local database engine, and in the (very rare) case there was another dbengX/dbsrvX running locally (and started before our own engine), it would try to load the (already loaded) database on the wrong engine. - As our users seem to have rarely used products with a permanently running "foreign" SQL Anywhere database engines, that background was difficult to track...
Personal resume: Another lesson learnt - though I would have bet that exactly that lesson was already learnt:).
Just to add: