The forum will experience an outage sometime between February 10 at 7:00pm EST and February 12 at 11:59 EST for installation of security updates. The actual time and duration of the outage are unknown but attempts will be made to minimize the downtime. We apologize for any inconvenience.

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:

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

asked 09 Mar '12, 07:52

Volker%20Barth's gravatar image

Volker Barth
accept rate: 32%

edited 09 Mar '12, 08:11

Specifying HOST=some-host-name is equivalent to specifying


and specifying HOST=some-host-name:1234 (note the port number) is the same as specifying:


and using HOST=some-host-name:1234;servername=myserver is the same as specifying:


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.

permanent link

answered 09 Mar '12, 09:10

Mark%20Culp's gravatar image

Mark Culp
accept rate: 40%

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.

(09 Mar '12, 09:18) Volker Barth
Replies hidden

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

(09 Mar '12, 09:27) Mark Culp

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.

(09 Mar '12, 09:29) Breck Carter
Replies hidden

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

(09 Mar '12, 09:37) Volker Barth

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

(09 Mar '12, 09:44) Volker Barth
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 09 Mar '12, 07:52

question was seen: 1,190 times

last updated: 09 Mar '12, 09:44