|
I have a locally running database server (12.0.1.4216, 32-bit) on a Windows 7 system running as normal application (i.e. not as a service). When I try to establish a local connection via ODBC (32-bit as well), the connection seems to use TCP/IP unless I explicitly specify "LINKS={ShMem}". Why is that? I'm not using the v12 HOST connection parameter - which would enforce TCP/IP even for local connections, AFAIK. (I had previously used that parameter but have dropped it now.) Instead I'm just using an ODBC DSN with SERVER= and DBN= and some other options but without any LINKS, HOST or PORT connection parameters. On a different box with Win 2K3, the same ODBC DSN settings do establish a ShMem connection as desired. Is that a Windows 7 peculiarity or what may prevent shared memory here? |
|
Sorry, I'm just to dump. I'm using a system DSN and changed it via the default (here: 64-bit) ODBC administrator and should of course have remembered that system DSNs are not sync'ed between 64-bit and 32-bit. So the 32-bit system DSN had still its HOST= parameter. Once I have modified the 32-bit system DSN, a ShMem connection is established as desired. Sigh. |
|
If the client does not specify HOST= or LINKS= connection parameters, the connection will be made over shared memory and not TCP/IP. I think there was a Windows CE exception to that in some case, but that is the only exception that I know of. Note that if the application or SQLCONNECT environment variable specifies HOST or LINKS= parameters, these will override values in the DSN. Try adding the LogFile connection parameter to the DSN when there is no LINKS parameter. The generated file will contain the the full connection string used to connect (combined from the application, SQLCONNECT and DSN). Thanks for the clarification, and yes, if I had used the LogFile parameter, it would have told me that the connection string does still contain a HOST= parameter... No Windows 7 peculiarity but one of mine:(
(02 Mar '15, 11:51)
Volker Barth
|
