Mystery Database IDs in Profiler

[Phil]

I'm currently running Profiler sessions to track down Lock Timeout
problems.

My Profiler view contains (amongst others) the dbid column.

Much of the time, this displays familiar dbids, such as 2 (tempdb) and
5 (my main user db). However, it also regularly displays IDs of 0 and
132.

Using SELECT DB_NAME(), these translate as "master" and "NULL"
respectively.

Does anyone know:
a) why dbid = 0 translates to "master", when the actual id of this
database is 1, and
b) why Profiler reports these dbids in the first place?

[John Bell]

Hi

Database ID is a default data column and should be populated for all events.
What other columns are you capturing? Which event is displaying this value?

Not directly related to your question but these may help:
http://support.microsoft.com/default...b;en-us;832524
http://msdn.microsoft.com/library/de...tabse_5xrn.asp
http://support.microsoft.com/kb/271509/EN-US/
John

"Phil" <ph*********@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

I'm currently running Profiler sessions to track down Lock Timeout
problems.

My Profiler view contains (amongst others) the dbid column.

Much of the time, this displays familiar dbids, such as 2 (tempdb) and
5 (my main user db). However, it also regularly displays IDs of 0 and
132.

Using SELECT DB_NAME(), these translate as "master" and "NULL"
respectively.

Does anyone know:
a) why dbid = 0 translates to "master", when the actual id of this
database is 1, and
b) why Profiler reports these dbids in the first place?

[Philip Yale]

"John Bell" <jb************@hotmail.com> wrote in message news:<42**********************@news.zen.co.uk>...

Hi

Database ID is a default data column and should be populated for all events.
What other columns are you capturing? Which event is displaying this value?
Have variously tried capturing just the columns I thought I needed,
and then finally capturing every column possible just in case this
altered any output!

The only event I'm capturing is the LOCK TIMEOUT event. I've since
noticed that these lock timeouts (with the dbid equal to 0 or 255) all
have the same lock type (which I can't remember right now, and I'm
nowhere that I can look it up conveniently), which essentially
translates to a "key range test for a record insert". i.e. they're
not proper locks at all, and so the timeout is almost certainly an
internal mechanism for releasing them

I was just intrigued why these were associated with a dbid at all, why
0 and 255 was chosen, and why 0 additionally translates to 'master'.

BTW - genuine lock timeouts correctly display valid database IDs.

Not directly related to your question but these may help:
http://support.microsoft.com/default...b;en-us;832524
http://msdn.microsoft.com/library/de...tabse_5xrn.asp
http://support.microsoft.com/kb/271509/EN-US/
John

"Phil" <ph*********@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

I'm currently running Profiler sessions to track down Lock Timeout
problems.

My Profiler view contains (amongst others) the dbid column.

Much of the time, this displays familiar dbids, such as 2 (tempdb) and
5 (my main user db). However, it also regularly displays IDs of 0 and
132.

Using SELECT DB_NAME(), these translate as "master" and "NULL"
respectively.

Does anyone know:
a) why dbid = 0 translates to "master", when the actual id of this
database is 1, and
b) why Profiler reports these dbids in the first place?

[John Bell]

Hi

It sounds like the INDID which will can be 0 or 255.

John
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!