Here's a guess: The following query will return NULL for internally-generated connections, also called temporary connections, whereas it will return an actual user name for client connections, event connections and web service connections:

SELECT CONNECTION_PROPERTY ( 'UserID', [connection-number] );

asked 19 Mar '12, 08:50

Breck%20Carter's gravatar image

Breck Carter
25.7k428592852
accept rate: 20%

edited 20 Mar '12, 08:57

Hm, I would have considered event connections internal ones, too... Or are you dealing with "temporary connections"?

(19 Mar '12, 08:58) Volker Barth
Replies hidden

...thanks for the terminology heads-up.

(19 Mar '12, 11:28) Breck Carter
Comment Text Removed

...the next question might be "How do I name temporary connections in all versions of SQL Anywhere?"

At least I was unaware of that term before v12 was released...

(19 Mar '12, 12:35) Volker Barth

I don't think you can... giving them connection names is a V12 enhancement that came with the (wonderful!) ParentConnection property.

(19 Mar '12, 15:01) Breck Carter

I assume you will already know all of this, and I know you asked about all versions but:

  • starting around version 9.0.1, connection_property( 'Number' ) is >= a billion for temporary connections (see dcx temporary connections) FYI event connections are classified as temporary in this case.
  • In version 12.x, connection_property( 'Name' ) starts with 'Int:' for temporary connections (I believe event connections don't start with 'Int:')
permanent link

answered 20 Mar '12, 08:45

Ian%20McHardy's gravatar image

Ian McHardy
3.0k23152
accept rate: 38%

Thanks... I am interested in distinguishing the internal connections from all the others, "temporary" or not. The Help seems to count only "INT:" connections in the definition of "temporary" but I don't care about the terminology... I just care about how to distinguish the internally-generated connections from all the others including clients, web services and events.

(20 Mar '12, 08:55) Breck Carter
Replies hidden
2

My guess based upon a how a number of internal connections are implemented is that most and perhaps all internal connections will have a NULL UserId as you initially ask in your question.

But I also expect that while a client connection is being established, it will briefly (for less than a millisecond normally) have a NULL UserId. So this test wouldn't be completely reliable. Perhaps this could be made more reliable by also checking something like connection_property( 'CommProtocol' ), which I think would be NULL for an event or internal connection.

(20 Mar '12, 09:56) Ian McHardy

Thanks! In this case, testing UserID is sufficient since the code is trying to exclude internal connections from being dropped because they are committing evil acts, like consuming all the CPU or blocking all other connections... and they probably can't do evil in the first millisecond :)

(20 Mar '12, 12:28) Breck Carter

AFAIK, with v12, event connections take the event name as their "name", and they do not have a parent connection, so they are easily distinguishable from "internal" connections.

permanent link

answered 20 Mar '12, 09:02

Volker%20Barth's gravatar image

Volker Barth
30.6k305455662
accept rate: 32%

Your answer
toggle preview

Follow this question

By Email:

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

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "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:

×20

question asked: 19 Mar '12, 08:50

question was seen: 944 times

last updated: 20 Mar '12, 12:28