I'm from a Linux+Postgres background so all this stuff about DSN, ODBC, and Microsoft Data Source Administrator is new to me. Is there any link/article that explains the following for a newbie:
PS: This is a follow-up from https://sqlanywhere-forum.sap.com/questions/35914/mobilink-connection-string-works-with-dbping-but-not-with-mlsrv |
Are you asking about DSN usage on Windows or on Linux? Here is a general link with further sub-topics: To your questions:
No, you can also just store some connection parameters (e.g. Servername/Host and DBN) in the DSN, and add others (say, UID etc.) when building the connection string - it's up to you...
DSNs on Windows can be either machine-specific (aka System DSNs) or machine-and-user-specific (User DSN), so yes, they are specific to the client machine. - Additionally, SQL Anywhere allows for non-machine-specific FileDSNs to share DSNs between machines. So you could use a FileDSN stored on a net share that can be used by different client machines. |
On Windows.
Note, Reg hasn't recommended to necessarily use a DSN but to always provide connection parameters for database server (host, servername, port if non-standard) and the database name (DBN=) in order to prevent undesired connections to other databases because SQL Anywhere uses several defaults by design - and that is not always too obvious. (Been there, done that.)
> Reg hasn't recommended to necessarily use a DSN
Actually, Reg did say exactly that: "The DSN parameter is required in the connection string for the MobiLink Server."
I can't remember ever having used a DSN-less connection to mlsrv17.exe, but the Help seems to imply it is possible: "Connection parameters must be included in the ODBC data source specification if not given in the command line."
It's worth testing, but I'm feeling lazy (step 1 would be "install Linux" :)
I use DSNless connections for MLSrv17. Lets assume that you are using SQL Anywhere 17. The basic DSNLess connection would look like:
If your consolidated is not SQLA, you simply need to determine the Driver Name to supply to 'driver' and connection parameters specific to that DBMS.
Oops, I apparently just focussed on Reg's comment, not his answer.