Does using the HOST connection parameter prevent local Shared Memory connections?

[VolkerBarth]

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...

[MarkCulp · Accepted solution]

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.

[VolkerBarth · Accepted solution]

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.

[MarkCulp · Accepted solution]

@Volker: I've sent a message to the doc team ... We'll see what we can do.

[Breck_Carter · Accepted solution]

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.

[VolkerBarth · Accepted solution]

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.)

[VolkerBarth · Accepted solution]

@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...