Глюк при создании #TMP таблиц из приложения

Приложение на ВБ 6, использую ADO 2.6 MS SQL 2000
При открытии рекордсета пишу следующее:
Tab="IF OBJECT_ID('tempdb..#WG') IS NULL CREATE TABLE #WG(IDG int,X int,Y int) ELSE TRUNCATE TABLE #WG"
Set Rs = New ADODB.Recordset
Rs.CursorLocation = adUseClient
Rs.Open Tab, Cn, adOpenKeyset, adLockOptimistic
Rs.Open "#WG", Cn, adOpenKeyset, adLockOptimistic
Далее работаю с этой таблицей.
Так вот есть два похожих куска кода(2 функции в ВБ), внутри одного класса.
В одном случае все работает нормально, в другом же - выдается ошибка при попытке открыть таблицу #WG. Слышал что такое бывает, но сам впервые столкнулся. Кто может помочь?
В базе tempDB в первом случае таблица создается, а во втором нет :(

? Точно Вы работаете в одном коннекте

Точно в одном. Коннект открывается при запуске приложения и удерживается до завершения работы.

Советую в Profiler посмотреть, есть предположение что для создания временной таблицы используется временная процедура. ADO любит так поступать.

Как только вы определеили adOpenKeyset, курсор стал сразу серверный. А в этом случае для второго запроса автоматом открывается дополнительное соединение, которое ничего не знает о созданной временной табличке в первом соединении.

2Dankov
Я же написал, что есть класс, в котором две разные процедуры создают одинаковым способом (одинаковым кодом) #таблицу. В 1 случае работает, во 2 - нет. А вот профайлер говорит обратное, так что я запутался!
Audit Login
set quoted_identifier on
set implicit_transactions off
set cursor_close_on_commit off
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
set language us_english
set dateformat mdy
set datefirst 7
SQL:BatchCompleted SET NO_BROWSETABLE ON
SQL:BatchCompleted IF OBJECT_ID('tempdb..#WG') IS NULL CREATE TABLE #WG(IDG int,X int,Y int) ELSE TRUNCATE TABLE #WG
Audit Logout
Audit Login
set quoted_identifier on
set implicit_transactions off
set cursor_close_on_commit off
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
set language us_english
set dateformat mdy
set datefirst 7
SQL:BatchCompleted SET NO_BROWSETABLE ON
SQL:BatchCompleted select * from #WG
SPID при этом отличается от SPIDа основного процесса.Почему так происходит?

Я имел ввиду, что профайлер подтверждает версию об открытии дополнительного соединения. Но я явно этого не делаю. И почем при вызове из другого куска кода этого не происходит?

Попробую подругому задать вопрос. В приложении я явным образом устанавливаю соединение с сервером 1 раз.
Cn.ConnectionTimeout = 25
Cn.Provider = "SQLOLEDB"
Cn.Properties("Data Source").Value = m_ServerName
Cn.Properties("Initial Catalog").Value = m_DBName
Cn.Properties("User ID").Value = m_UserName
Cn.Properties("Password").Value = m_Password
Cn.Open
Предположим оно(соединение) имеет SPID 53. Далее я в проекте использую это соединение для открытия различных рекордсетов. Почему в одних случаях рекордсеты открываются через соединение 53, а в других через новое с номером 54, которое тут же закрывается. Код для создания и открытия рекордсетов находится внутри класса, поэтому на разный синтаксис грешить нельзя. Он (SQL сервер) что, таким образом распараллеливает процессы? Или что еще заставляет откыть новое соединение, причем как-то неявно??? Объясните пожалуйста!

ADO открывает дополнительное соединение в том случае, если основное занято фетчем выборки.

По моему ответу уже давно надо было догадаться, что проблема решается просто заданием клиентского курсора, т.е. отказа от adOpenKeyset. С клиентским курсором совместим только adStatic. Остальные установки приводят к переустановке курсора в серверный, получения дополнительных соединений на каждый случай недофетченного курсора и траблам с временными таблицами.

2Dankov
Вы напрасно считаете, что я не попробывал открывать рекордсет с различными свойствами, в т.ч. и adOpenStatic, прежде чем задать вопрос. После Вашего ответа, я еще раз перепроверил, на всякий случай. НЕ ПОМОГЛО!
По поему вопросу можно было понять что в двух идентичных по синтаксису процедурах ADO реагировало по разному! Это и ставило меня в тупик.
Проблему я решил, но не подстановкой adOpenStatic, а тем что сменил метод получения рекордсета в процедуре выполняемой непосредственно перед интересующей меня операцией.