|
Что лучше, передать большой массив в процедуру или все-же таблицу
|
|||
---|---|---|---|
#18+
Есть проблема - передать большой массив в процедуру, так как вызов процедур для каждого элемента массива в цикле продолжается минут 15 . Вот видел я описание параметра как Array, но никак не удается попробовать. и потом как его обработать? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2000, 19:37 |
|
Что лучше, передать большой массив в процедуру или все-же таблицу
|
|||
---|---|---|---|
#18+
А конкретней можно по вопросу непонятна бизнес логика, массив какой в процедуру какую паскасль или SQL, ... |
|||
:
Нравится:
Не нравится:
|
|||
21.12.2000, 10:31 |
|
Что лучше, передать большой массив в процедуру или все-же таблицу
|
|||
---|---|---|---|
#18+
ARRAY, как зарезервированное слово я видел, но как тип данных ..? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.12.2000, 20:19 |
|
Что лучше, передать большой массив в процедуру или все-же таблицу
|
|||
---|---|---|---|
#18+
Да вот что конкретно. Есть мулька типа сервера безопасности. ты выделяешь список объектов в эксплорере, а потом указанному пользователю даешь Grant. Существует процедурка пока что, которая берет в качестве параметра один SID объекта и Item_ID пользователя и увязывает их. И вот я получаю список SID объектов, которые выделил админ - а их там тысяч 20. И в цикле запускаю процедуру GRANT, которая на каждый SID выдает Grant пользователю. Притом есть еще одна беда. Так как все написано на Бэйсике с реализацией DCOM, то клиент посылает на сервер массив SID, после чего создается ощущение, что он висит... ясно он висит, пока удаленный сервер не пропишет все циклы. А раз это длится минут 20 (так как я понял, что SQL server 7.0 делает порядка 2000 транзакций в минуту), то юзер может не выдержать. Если вызов цикла перенести на клиента, то можно показать Progress Bar, и тогда время выполнения увеличивается в 2 раза, то есть до 40 минут. Нужно весь массив закинуть в процедуру SQL-Server, чтобы он ее там обработал. Я думаю, что секунд 20 ему хватит. Но как это сделать - не знаю. Есть еще идея все закачать в отсоединенный рекордсет и передать его в процедуру, но как и что с ним потом делать? Буду благодарен за любой совет. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2000, 11:18 |
|
Что лучше, передать большой массив в процедуру или все-же таблицу
|
|||
---|---|---|---|
#18+
Стояла немного другая задача: требовалось из PB перенести на сервер получение списка характеристик счетов, при том, что пользователь сам выбирал массив их идентификаторов. Ничего лучше, чем сформировать строку (Comma separated) и передать её в пр-ру как text, на ум не пришло. Далее шёл простой EXECUTE("...") ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2000, 11:54 |
|
Что лучше, передать большой массив в процедуру или все-же таблицу
|
|||
---|---|---|---|
#18+
Передать большой объем данных со сложной стуктурой можно с использованием XML. Например спмсок пар SID и Item_ID можно ппредставить в виде XML текста <ROOT> <R SID="1" Item_ID="10"> </R> <R SID="2" Item_ID="20"> </R> <R SID="3" Item_ID="30"> </R> <R SID="4" Item_ID="40"> </R> </ROOT>' и передать его в процедуру. В процедуре из этого текста можно получить таблицу пар SID и Item_ID следующим образом (примеры есть в BO): DECLARE @idoc int DECLARE @doc varchar(1000) -- исходные данные SET @doc =' <ROOT> <R SID="1" Item_ID="10"> </R> <R SID="2" Item_ID="20"> </R> <R SID="3" Item_ID="30"> </R> <R SID="4" Item_ID="40"> </R> </ROOT>' EXEC sp_xml_preparedocument @idoc OUTPUT, @doc SELECT * FROM OPENXML (@idoc, '/ROOT/R',2) WITH (SID int '@SID', Item_ID int '@Item_ID') результат: SID Item_ID ----------- ----------- 1 10 2 20 3 30 4 40 ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2000, 10:56 |
|
Что лучше, передать большой массив в процедуру или все-же таблицу
|
|||
---|---|---|---|
#18+
Еще можно завести таблицу спецально для передачи таких данных. Одна из колонок будет какой-то уникальный идентификатор, другая колонка с данными(например SID объекта). В одном месте надо будет вставить записи в таблицу с неким идентификатором, а затем вызвать процедуру на SQL(её естественно надо написать) и как параметр передать это идентификатор. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2000, 12:56 |
|
Что лучше, передать большой массив в процедуру или все-же таблицу
|
|||
---|---|---|---|
#18+
Для варианта SergSuper лучше использовать временную таблицу. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2000, 19:41 |
|
Что лучше, передать большой массив в процедуру или все-же таблицу
|
|||
---|---|---|---|
#18+
Решил, вот, проверить пример VadimB. Дык, что-то ничего не получается (. Ругается : Could not find stored procedure 'sp_xml_preparedocument'. ... а также непонятки с OPENXML (@idoc, '/ROOT/R',2) Я чего-то не то делаю? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2000, 10:18 |
|
Что лучше, передать большой массив в процедуру или все-же таблицу
|
|||
---|---|---|---|
#18+
Поддержка XML есть только в MS SQL2000. Тексты примеров можно взять в BO из раздела sp_xml_preparedocument. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2000, 10:45 |
|
Что лучше, передать большой массив в процедуру или все-же таблицу
|
|||
---|---|---|---|
#18+
Нужен SQL Server 8.0 (a.k.a. 2000). Кстати, вопрос: можно ли Open XML Rowset Provider'у дать на вход имя файла? Или единственный выход - формировать XML как строку внутри батча? Тогда непонятно, как быть с XML-документами, чей размер превышает 8К. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2000, 10:50 |
|
Что лучше, передать большой массив в процедуру или все-же таблицу
|
|||
---|---|---|---|
#18+
Ксли размер данных в формате XML больше 8K, то для этого в процедуре sp_xml_preparedocument второй параметр может иметь тип text или ntext. А передать серверу более 8К это проблема клиента ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2000, 15:35 |
|
|
start [/forum/topic.php?fid=46&msg=32001281&tid=1827521]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
50ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
others: | 273ms |
total: | 415ms |
0 / 0 |