Xpoint
   [напомнить пароль]

работа с глобальной временной таблицей ##

Метки: [без меток]
2007-02-06 12:04:40 [обр] Леонид Валитов(0/3)[досье]
Здравствуйте
хотел было поработать с subj однако встретил непреодолимые трудности
первый вошедший нормально создает табличку и использует ее
но вот второй должен проанализировать создавать ему табличку или использовать имеющуюся
и никак это не получается
sa может явно проверить наличие таблички а другому юзеру прав не хватает
явно дать юзеру права на tempdb получается только до перезапуска сервера
после перезапуска он про эти права забывает
не посоветует ли кто как такое преодолеть
спустя 18 часов [обр] Top manager(0/2)[досье]
Леонид Валитов[досье] сорр ща голупый вопрос, а что это *subj *?
спустя 1 час 21 минуту [обр] Леонид Валитов(0/3)[досье]
таким образом обычно обозначают тему сообщения чтобы не повторяться
очень полезный уточняющий вопрос, спасибо, +3 очка вам
спустя 2 часа 48 минут [обр] Алексей Рюмин aka Dwarf(120/864)[досье]

Леонид Валитов[досье]

create table ##t (id int)
select object_id('tempdb..##t')
drop table ##t

- работает?

спустя 57 минут [обр] Леонид Валитов(0/3)[досье]

вот блин!
я как умная маша делаю как у микрософта пишется
if not exists (select * from tempdb.dbo.sysobjects where id = object_id(N'tempdb.dbo.##t'))
create table ##t (ID int)
и оно меня посылает
хотя достаточно
if object_id(N'tempdb.dbo.##t') is null
create table ##t (ID int)

спасибо

спустя 5 месяцев [обр] Леонид Валитов(0/3)[досье]
собрался таки применить эту штучку для формирования репортов
но есть некоторые сомнения
предполагаю сделать что-то типа
if object_id(N'tempdb.dbo.##t') is null
  create table ##t (spid int default(@@spid), .....)
delete ##t where spid=@@spid
insert ##t(....)
select ... --большой и тяжелый селект
и далее уже много всяких селектов к имеющимся строкам
select ... from #t where spid=@@spid
дак вот сомнения заключаются в том не начнут ли несколько одновременно запускаемых продобных процессов лочить друг друга
или может еще чего портить
был у меня уже опыт когда пришлось разбираться с некоторым багом
и там оказалось что происходила работа с временной таблицей в триггере из stored procedure т.е под implicit transaction
и все это лочило tempdb и на некоторых серверах вообще отказывалось работать
хотя там было все неочевидно и на другом сервере этот же дамп нормально отрабатывал
но разрешилась ситуация именно переделкой временных таблиц на постоянные
с тех пор я с опаской отношусь к временным таблицам
хотя в некоторых случаях и возникает желание их использовать
не может ли кто подсказать о надежности такого решения
Powered by POEM™ Engine Copyright © 2002-2005