on 2012 Mar 09 7:52 AM
As a follow-up to this question, I have just found out that specifying the new v12 HOST connection parameter forces local connections to use TCP/IP instead of Shared Memory. I was not aware of that...
Reading the docs, I've noticed it is documented that way, and that HOST is primarily meant for connections to remote machines. However, the following quote
The Host connection parameter is optional for connections to a personal server, and recommended for connections to a network server.
does not clearly tell that local connections will then use TCP/IP instead of shmem.
And the following quote from the CommLinks parameter doc page seems to recommend HOST as well:
Note
In most cases, you should use the HOST connection parameter. See Host connection parameter.
You should only use the CommLinks (LINKS) connection parameter if you need to specify TCP/IP options other than Host or ServerPort (PORT). You cannot specify both CommLinks and Host in the connection string.
Question: Is there a way to specify HOST and still use shared memory locally?
When migrating to v12, I have understood the introduction of the HOST connection parameter primarily as a means to improve over the former usage of "LINKS={TCPIP(HOST=...)" options, and to add it to the existing ENG/Server parameter. So I made of use it in typical ODBC DSNs that are used identically on several boxes - including the one where the engine is running. - Now I think that for the applications on the engine box itself, that has not been an improvement...
I'm not quite sure if I'm primarily asking a question or trying to hint at a better documentation of the side effects or just giving a warning...
Request clarification before answering.
Specifying HOST=some-host-name
is equivalent to specifying
LINKS=TCPIP{host=some-host-name:2638;DoBroadcast=None;Verify=No}
and specifying HOST=some-host-name:1234
(note the port number) is the same as specifying:
LINKS=TCPIP{host=some-host-name:1234;DoBroadcast=None;Verify=No}
and using HOST=some-host-name:1234;servername=myserver
is the same as specifying:
LINKS=TCPIP{host=some-host-name:1234;DoBroadcast=None;Verify=Yes};servername=myserver
so as a side effect of using the HOST connection parameter you are indicating that you want to use TCP/IP.
There is currently no method of using the HOST connection parameter and still use shared memory locally. This is an interesting possibility as an enhancement for a subsequent release and we will consider it.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Mark, that's a great documentation enhancement, particularly as there has been some confusion between the HOST connection parameter and the HOST protocol option - please add this to DCX...
Given this explanation, I think the "recommendation to use HOST" in the docs should be more precise: It should clearly point out that "you are indicating to use TCP/IP" and that this is not generally recommended for local connections.
Choosing to use the same keyword HOST for a connection parameter as well as the network connection parameter, while giving it new and different functionality, was a HUGE MISTAKE.
It isn't just the name, however... the very existence of the HOST connection parameter was a mistake... it wasn't needed, and it serves only to obfuscate, not simplify.
Fortunately, folks can avoid the confusion ("is it Verify Yes or Verify No?") by choosing to NEVER USE the HOST connection parameter... use LINKS instead. LINKS works just fine, without the obfuscation.
To add another issue:
My previous misunderstanding is surely influenced by the fact that specifying ENG or Server has always been "good" both for local and remote connections, i.e. it would do "no harm" for local connections even if it would not have been necessary.
In the way, the HOST connection parameter seems to behave differently, and that's a relevant difference, methinks.
(Yes, I'm aware that local TCP/IP connections do work, so using them is simply sub-optimal.)
@Breck: Well, I guess while writing the "SQL Anywhere 12 TOP 10" document your point of view was different, wasn't it - "HOST is no more a mere hint to the host name / IP address to use but a true specification..." (in my words)...
Besides that, I agree with your point: For folks used to the LINKS parameter, the new behavour is at least surprisingly...
User | Count |
---|---|
76 | |
30 | |
8 | |
8 | |
7 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.