Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Массив в Хранимую Процедуру  [new]
vah
Member

Откуда:
Сообщений: 2694
Возможно ли передать массив из приложения в Хранимую Процедуру?


Заранее благодарен.
29 сен 09, 22:42    [7722541]     Ответить | Цитировать Сообщить модератору
 Re: Массив в Хранимую Процедуру  [new]
PaulYoung
Member

Откуда: Москва
Сообщений: 2566
vah,

массивы и списки в SQL Server
29 сен 09, 22:45    [7722546]     Ответить | Цитировать Сообщить модератору
 Re: Массив в Хранимую Процедуру  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
Если сервер 2008 - http://msdn.microsoft.com/ru-ru/library/bb510489.aspx
30 сен 09, 06:32    [7722815]     Ответить | Цитировать Сообщить модератору
 Re: Массив в Хранимую Процедуру  [new]
Ken@t
Member

Откуда: 大地
Сообщений: 3265
ещё xml. но осторожно.
Кстати в поиске это всё находится на раз, вы ещё не научились им пользоваться ?
30 сен 09, 08:27    [7722894]     Ответить | Цитировать Сообщить модератору
 Re: Массив в Хранимую Процедуру  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
Ken@t
ещё xml. но осторожно.
Это описано в статье, ссылку на которую дал PaulYoung.
30 сен 09, 08:30    [7722898]     Ответить | Цитировать Сообщить модератору
 Re: Массив в Хранимую Процедуру  [new]
Ken@t
Member

Откуда: 大地
Сообщений: 3265
tpg,

таки да. Что-то в памяти отложилось, что распарсивание строки по делемитерам. Хотя для >=2005 xml нормальный тип данных для сериализации и десериализации списков и параметров.
30 сен 09, 09:34    [7723051]     Ответить | Цитировать Сообщить модератору
 Re: Массив в Хранимую Процедуру  [new]
vah
Member

Откуда:
Сообщений: 2694
Ken@t
tpg,

таки да. Что-то в памяти отложилось, что распарсивание строки по делемитерам. Хотя для >=2005 xml нормальный тип данных для сериализации и десериализации списков и параметров.


я надеялся, что можно передать данные в ХП с типом table...
30 сен 09, 09:54    [7723147]     Ответить | Цитировать Сообщить модератору
 Re: Массив в Хранимую Процедуру  [new]
Паганель
Member

Откуда: Винница
Сообщений: 22550
vah
я надеялся, что можно передать данные в ХП с типом table...
Так Вы со своего 2000-го перейдите на 2008-й, и Ваши надежды начнут сбываться
30 сен 09, 10:00    [7723178]     Ответить | Цитировать Сообщить модератору
 Re: Массив в Хранимую Процедуру  [new]
Ken@t
Member

Откуда: 大地
Сообщений: 3265
vah


я надеялся, что можно передать данные в ХП с типом table...

В BOL написано, что можно передавать в ХП. так и неудосужились прочитать ?

ещё можно создать временную таблицу , заполнить её данными и вызвать ХП из которой и работать со списком.
30 сен 09, 10:01    [7723182]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: Массив в Хранимую Процедуру  [new]
Serg_77m
Member

Откуда: Донецк
Сообщений: 237
Может, это уже и не слишком актуально, но для MSSQL 2000+ есть ещё один способ передачи таблицы в процедуру. Быстрый, но с ограничениями: параметр у процедуры только один, и нет возможности вернуть результат.

Описание:
1. создать из чего угодно view (хотя бы из констант), у которого структура соответствует таблице-параметру.
2. навесить на этот view триггер instead of insert. В теле триггера пишем код процедуры.

Всё. Теперь, чтобы запустить процедуру, пишем insert into созданный_view ..., при этом запускается триггер, в котором таблица inserted соответствует переданной таблице.
19 апр 13, 12:19    [14202895]     Ответить | Цитировать Сообщить модератору
 Re: Массив в Хранимую Процедуру  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Serg_77m,
+100500

Процедурномыслящим этого не понять. Для них слово триггер это из разряда тёмных сил электричества.
А ещё там бонус - автоматическая транзакция.

Serg_77m
параметр у процедуры только один
А это очень интересная тема. Понятие датасета не хватает.
Тут нужно хотя бы про язык D почитать.

PS: Ссори, не удержался.
19 апр 13, 12:52    [14203221]     Ответить | Цитировать Сообщить модератору
 Re: Массив в Хранимую Процедуру  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
Ken@t
ещё xml. но осторожно.
Кстати в поиске это всё находится на раз, вы ещё не научились им пользоваться ?


а смысл?
19 апр 13, 12:57    [14203277]     Ответить | Цитировать Сообщить модератору
 Re: Массив в Хранимую Процедуру  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31948
Serg_77m
и нет возможности вернуть результат.
Это почему не вернуть? Нормально возвращается результат из триггера.
Mnior
А ещё там бонус - автоматическая транзакция.
Это наверное сарказм? :-)
Лучше неавтоматически поуправлять...

ИМХО способ остроумный, но не более - 2 глобальных недостатка (один параметр + автоматическая транзакция) делают его просто интересной "шуткой программиста".
19 апр 13, 13:01    [14203300]     Ответить | Цитировать Сообщить модератору
 Re: Массив в Хранимую Процедуру  [new]
iap
Member

Откуда: Москва
Сообщений: 47142
alexeyvg
Нормально возвращается результат из триггера.
Вставкой в таблицу какую-нибудь?
Или что имеется в виду?
19 апр 13, 13:42    [14203634]     Ответить | Цитировать Сообщить модератору
 Re: Массив в Хранимую Процедуру  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31948
iap
alexeyvg
Нормально возвращается результат из триггера.
Вставкой в таблицу какую-нибудь?
Или что имеется в виду?
Имеется в виду, что если там сделать селект, то результат вернётся в приложение.
19 апр 13, 15:41    [14204733]     Ответить | Цитировать Сообщить модератору
 Re: Массив в Хранимую Процедуру  [new]
iap
Member

Откуда: Москва
Сообщений: 47142
alexeyvg
iap
пропущено...
Вставкой в таблицу какую-нибудь?
Или что имеется в виду?
Имеется в виду, что если там сделать селект, то результат вернётся в приложение.
Осторожнее!
CREATE TRIGGER (Transact-SQL)
Общие соглашения о триггерах
Возвращаемые результаты
Возможность возвращать результаты из триггеров будет исключена из следующей версии SQL Server.
Триггеры, возвращающие результирующие наборы, могут привести к непредвиденному поведению приложений,
не предназначенных для работы с ними.Не используйте в разрабатываемых приложениях триггеры, возвращающие
результирующие наборы, и запланируйте изменение приложений, которые используют их в настоящее время.
Чтобы триггеры не возвращали результирующие наборы, для параметра disallow results from triggers необходимо установить значение 1.


http://msdn.microsoft.com/ru-ru/library/ms189799.aspx
19 апр 13, 16:09    [14204996]     Ответить | Цитировать Сообщить модератору
 Re: Массив в Хранимую Процедуру  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31948
Возвращаемые результаты
Возможность возвращать результаты из триггеров будет исключена из следующей версии SQL Server.
Ужас.
19 апр 13, 16:18    [14205078]     Ответить | Цитировать Сообщить модератору
 Re: Массив в Хранимую Процедуру  [new]
Serg_77m
Member

Откуда: Донецк
Сообщений: 237
[quot alexeyvg]
Serg_77m
и нет возможности вернуть результат.
Это почему не вернуть? Нормально возвращается результат из триггера.
В обычных процедурах есть код возврата. У триггеров его нет. Разве что через raiserror какой-нибудь.
А в приложение выборку вернуть, конечно, можно. Несмотря на предупреждения Microsoft'а. Всё равно для MSSQL 2008+ оно уже неактуально.
Ну или во временную таблицу можно записать... но тогда и параметр можно через временную таблицу передать.
19 апр 13, 17:06    [14205554]     Ответить | Цитировать Сообщить модератору
 Re: Массив в Хранимую Процедуру  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
alexeyvg
Возвращаемые результаты
Возможность возвращать результаты из триггеров будет исключена из следующей версии SQL Server.
Ужас.
Да у нас уже несколько лет стоит эта опция. И правильно что нельзя.
Без неё OUTPUT не работает, к примеру.

alexeyvg
Это наверное сарказм? :-)
ИМХО способ остроумный, но не более ...
Если воспринять мой пост целиком, а не кусочками, то вопрос сразу отпадает.
См. отсылку к языку D. Если вы не в курсе, то вы ещё не поняли что я имел ввиду.

Одновременное изменение нескольких объектов, передача целостных датасетов. Вот я к чему.
Ибо ни триггера, ни процедуры - не решают проблем. Пока всё что сейчас есть, это детский лепет и каменный век.

alexeyvg
Лучше неавтоматически поуправлять...
Чего? Зачем?
Не надо какие-то проблемы складывать на то к чему они не относятся. Атомарность действий это закон.
Естественно есть код императивный и моск его обслуживающий тоже, то сразу надо остальным делать кучу неудобств и тупых ограничений?!
Это я не к вам, а к возможным возражениям.
19 апр 13, 18:25    [14206112]     Ответить | Цитировать Сообщить модератору
 Re: Массив в Хранимую Процедуру  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31948
Mnior
Не надо какие-то проблемы складывать на то к чему они не относятся. Атомарность действий это закон.
Естественно есть код императивный и моск его обслуживающий тоже, то сразу надо остальным делать кучу неудобств и тупых ограничений?!
Ну при чём тут "императивный моск" :-)

Атомарность действий - это не закон, а инструмент, атомарность совершенно необязательна для функциональных языков, реляционных баз данных и т.п.
Mnior
Одновременное изменение нескольких объектов, передача целостных датасетов. Вот я к чему.
Ибо ни триггера, ни процедуры - не решают проблем. Пока всё что сейчас есть, это детский лепет и каменный век.
Это да, согласен, я бы хотел, что бы сиквел развивался интенсивнее и в неком похожем направлении.
19 апр 13, 19:00    [14206261]     Ответить | Цитировать Сообщить модератору
 Re: Массив в Хранимую Процедуру  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
alexeyvg
Атомарность действий - это не закон, а инструмент, атомарность совершенно необязательна для функциональных языков, реляционных баз данных и т.п.
Или я вас не понял или вы плохо выразились.
Со стороны декларативных языков, атомарность это инструмент реализации. Для самого языка это не то что закон, это основной базовый принцип. Точнее вообще у них нет понятия неатомарности (и такого разделения). Разделение это проблемы императивности мира.

Но с другой стороны, я имел ввиду под атомарностью - целостность нескольких изменений/команд, не связанных физически (издержки реализации), но логически. И в большей степени запросы к базе пораждают одно целостное (естественно) изменение. Остальное редкость.

И то что дефолтное поведение стоит дороже (как задолбала стандартная мега-конструкция процедур) чем редкое - не есть хорошо.
Вот если бы по умолчанию процедура порождала транцакцию - это было просто охренительно круто. А если надо что-то накосячить, укажи в опциях процедуры (типа WITH NOT_IN_TRANSACTION) или в настройках сервера.

Но лучше уж команда MERGE датасета с базой, чем что-то улучшать в такой нелепице как "хранимая процедура".
Тогда останутся только две команды. SELECT датасета и MERGE датасета. И возможно даже одна (есть или нет одного из двух блоков).
И если у кого-то не получается делать запросы в одну команду - пусть этот гуманитарий меняет профессию на подходящую. ;-)

PS: Опять у меня словесный понос и отошёл от темы.
19 апр 13, 23:52    [14206867]     Ответить | Цитировать Сообщить модератору
 Re: Массив в Хранимую Процедуру  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31948
Mnior
Но лучше уж команда MERGE датасета с базой, чем что-то улучшать в такой нелепице как "хранимая процедура".
Тогда останутся только две команды. SELECT датасета и MERGE датасета. И возможно даже одна (есть или нет одного из двух блоков).
И если у кого-то не получается делать запросы в одну команду - пусть этот гуманитарий меняет профессию на подходящую. ;-)
Мне больше нравятся многопарадигменные языки (идеал - C/C++) :-)

А ваш подход красивый, но недостижимый. Без императивщины не может быть программирования и компьютера. В конце концов, эти ваши SELECT датасета и MERGE нужно вызвать, а для вас само понятие вызвать является недопустимой императивщиной.

Чистым ваш подход был бы, если бы функциональный язык описывал приложение целиком как формулу, но по сути понятие программирования появилось, когда изобрели вот этот самый императивный подход. А функциональные ЯП, и их реализации, в том числе SQL, являются просто используемыми формулами для императивных ЯП, то есть по сути чем то вторичным, второстепенным.
Mnior
Вот если бы по умолчанию процедура порождала транцакцию - это было просто охренительно круто.
Так есть же режим такой, SET IMPLICIT_TRANSACTIONS, можно при создании коннекта всегда выполнять...
20 апр 13, 00:13    [14206896]     Ответить | Цитировать Сообщить модератору
 Re: Массив в Хранимую Процедуру  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
alexeyvg
Без императивщины не может быть программирования и компьютера.
... само понятие вызвать является недопустимой императивщиной
1. Не надо всё под одну гребёнку нести.
2. Как раз всё нормально ложится, система есть реакция на внешнее команды. Программа есть формализм, формула связи нового состояния по отношению к старому. Как и почему приходят внешние раздражители лежит вне программы и даже вне железа.
Есть абсолютно чистые языки использующиеся в продакшине.

Теория чиста, вот реализовывать сложно - это да. А ещё сложно отсеивать процедурно-мыслящих лентяев (либо природа на них отдахнула или им лень пользоваться моском).

От костылей (мульти-парадигменности) избавиться невозможно (и не нужно). Но если язык позволяет так же легко писать неправильно (императивно) как и положено - то это свинский язык. Это самый главный корень проблемы тормозов технического прогресса. Уже сейчас все основные языки намного ближе к декларативным, чем к императивным, чем раньше (когда начался двусторонний срач). Кто громче кричал (толпа), оказался неправ, как обычно. Спираль заканчивается, N-ацать лет уже ушло коту под хвост, в бесчисленной человеческой возне.

alexeyvg
но по сути понятие программирования появилось, когда изобрели вот этот самый императивный подход. А функциональные ЯП, и их реализации, в том числе SQL, являются просто используемыми формулами для императивных ЯП, то есть по сути чем то вторичным, второстепенным.
Что-то у вас в истории языков большие пробелы. Декларативные языки и их формализмы появились за долго до появления вычислительной машины. И более того, именно решалась проблема автоматизации доказательств и формального вывода из которого и вышла теория вычислимости и т.п.
Так что не надо путать причину и следствие. То что гуманитарная предприимчивость получить профит из чего-то, вырвав его из контекста (привет распилы), не является первопричиной всего, а банальное следствие (побочное явление) человеческого бытия.
Хрен-лет назад вспомнили про первоначальную идею, успешно реализовали (декларативные языки в текущем виде очень старые и почти не менялись), потом опять втоптали в грязь, а потом опять переняли почти всё что было на современные.
Поменьше бы соплей, да побольше моском думать.
Осталось дождаться когда машина пятого поколения восстанет из пепла, но до этого ещё далеко.

мульти-парадигменности - это не подход к лучшему, это постепенный переход толпы от императивизма к декларативизму. Промежуточное смешанное состояние.

И другая сторона. Это сейчас мода такая. Делаем потому что можем, а давайка повысим сложность, закомбинируем всё и вся. Симулякрия в квадрате, в кубе в бесконечной степени. Побесимся с жиру, зачем зырить в корень, давай бездумно генерить и плодить, делать видимость процессов. Людей же занять надо "работой". А всё потому что работать надо обязательно. А как мы знаем, обязаловка ни к чему хорошему привести не может. Такие дела, и устои у современного племени.

Mnior
Так есть же режим такой, SET IMPLICIT_TRANSACTIONS, можно при создании коннекта всегда выполнять...
Знал что вы зададите этот вопрос.
У IMPLICIT_TRANSACTIONS есть свои неприятные побочные вещи. Но в принципе - наличие такой вещи уже говорит о многом. Или вы хотите сказать что юзаете эту опцию? :-)
Более того, это обёрка из одной транзакции, но если вызывается процедура в процедуре - должна быть матрёшка (с возможностью отката до поинта и админшами). :-)
Вызов команды MERGE или EXEC должны быть атомарны одинаково (по умочанию).
20 апр 13, 01:44    [14207014]     Ответить | Цитировать Сообщить модератору
 Re: Массив в Хранимую Процедуру  [new]
cooldeveloper
Member [заблокирован]

Откуда: МСУ
Сообщений: 484
Serg_77m
Может, это уже и не слишком актуально, но для MSSQL 2000+ есть ещё один способ передачи таблицы в процедуру. Быстрый, но с ограничениями: параметр у процедуры только один, и нет возможности вернуть результат.

Описание:
1. создать из чего угодно view (хотя бы из констант), у которого структура соответствует таблице-параметру.
2. навесить на этот view триггер instead of insert. В теле триггера пишем код процедуры.

Всё. Теперь, чтобы запустить процедуру, пишем insert into созданный_view ..., при этом запускается триггер, в котором таблица inserted соответствует переданной таблице.


Жесть, просто безумная жесть :)
22 апр 13, 10:17    [14211392]     Ответить | Цитировать Сообщить модератору
 Re: Массив в Хранимую Процедуру  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
cooldeveloper
Жесть, просто безумная жесть :)
Не по феншую?
22 апр 13, 14:06    [14212778]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить