Форум: "Базы";
Текущий архив: 2015.05.03;
Скачать: [xml.tar.bz2];
ВнизПередать BLOB без использования Temporary LOB Найти похожие ветки
← →
dima1983 (2010-06-17 17:56) [0]Нужно передать параметр BLOB в хранимую процедуру без использования временного LOB локатора. Используются компоненты DOA. Оказалось, что на машине стоят 8 клиены, а они не работают со временными LOBами :).
Сейчас вот так:
...
LOB := TLOBLocator.CreateTemporary(Oq.Session, otBLOB, true);
LOB.CopyFrom(ms,ms.size);
(*
Здесь ms это поток, который содержит передаваемые данные
*)
with OQ do begin
SetComplexVariable("sDoc",LOB);
...
Execute;
Doc.sNameDoc:=GetVariable("id");
...
Session.Commit;
end;
← →
Правильный$Вася (2010-06-17 19:10) [1]
> Оказалось, что на машине стоят 8 клиены
так заменить на те, которые соответствуют серверу
я, кстати, неоднократно сталкивался с неработоспособностью в некоторых случаях комбинаций разных версий клинетов и сервера, что моментально исчезало при синхронизации версий
так что не костыли нужно делать, а переломы лечить
← →
dima1983 (2010-06-17 19:41) [2]
> > Оказалось, что на машине стоят 8 клиены
>
> так заменить на те, которые соответствуют серверу
> я, кстати, неоднократно сталкивался с неработоспособностью
> в некоторых случаях комбинаций разных версий клинетов и
> сервера, что моментально исчезало при синхронизации версий
>
> так что не костыли нужно делать, а переломы лечить
Обязательно, особенно если клиентов несколько тысяч от Калиненграда до Камчатки, это ж как 2 байта переслать :) поменять пару строчек в программе гораздо сложнее :)
Ведь до 8 клиента передавались же как-то BLOB в хранимые процедуры?
← →
Правильный$Вася (2010-06-17 19:57) [3]
> клиентов несколько тысяч от Калиненграда до Камчатки
кто хочет - ищет пути, кто не хочет - ищет отмазки
← →
dima1983 (2011-04-11 00:07) [4]Нашёл случайно свой старый вопрос :)))
Поскольку нормальных ответов на на него так никто и не дал напишу своё решение. Оно очень простое.
1) Создаете табличку в БД с полем BLOB
2) Делаете в неё insert (без использования временного LOB локатора)
3) А в процедуру передаете RowId, главное потом не забыть удалить в процедуре после считывания ненужную строчку :))))
Вот так всё просто и не нужно на Камчатку ехать клиенты обновлять :))) экономит массу гос.средств :)
← →
Кщд (2011-04-11 08:04) [5]>dima1983 (11.04.11 00:07) [4]
2) Делаете в неё insert (без использования временного LOB локатора)
3) А в процедуру передаете RowId, главное потом не забыть удалить в процедуре после считывания ненужную строчку :))))
global temporary table.
и пляски с rowid - чреваты, ибо для записи он может меняться со временем.
поэтому лучше заводить честный PK.
← →
dima1983 (2011-04-13 11:55) [6]
> global temporary table.
> и пляски с rowid - чреваты, ибо для записи он может меняться
> со временем.
> поэтому лучше заводить честный PK.
8ой клиент клиент!!! ну читайте же вопрос!
И зачем заводить PK если таблица только для твоего приложения и строчка в ней живет менее минуты.
← →
Кщд (2011-04-13 12:07) [7]>dima1983 (13.04.11 11:55) [6]
>8ой клиент клиент!!! ну читайте же вопрос!
8-ой клиент не поддерживает работу с GTT?
>И зачем заводить PK если таблица только для твоего приложения и строчка в >ней живет менее минуты.
затем, что достоверно полагаться можно на PK, но нельзя на rowid
← →
dima1983 (2011-04-14 22:15) [8]
> >dima1983 (13.04.11 11:55) [6]
> >8ой клиент клиент!!! ну читайте же вопрос!
> 8-ой клиент не поддерживает работу с GTT?
>
> >И зачем заводить PK если таблица только для твоего приложения
> и строчка в >ней живет менее минуты.
> затем, что достоверно полагаться можно на PK, но нельзя
> на rowid
Думаю дальше диалог бессмыслен.
Вы такой классный специалист куда там!
← →
Кщд (2011-04-15 04:31) [9]>dima1983 (14.04.11 22:15) [8]
каждый сам мостит себе дорогу в ад)
успехов)
← →
ANB (2011-04-25 11:41) [10]
> затем, что достоверно полагаться можно на PK, но нельзя
> на rowid
В данном случае rowid проще и лучше PK.
А еще лучше - писать только одну запись и чистить табличку. И не надо ПК и rowid.
PS. А раньше только через таблички и писали лобы, временные лобы уже потом накопали.
← →
ANB (2011-04-25 11:42) [11]
> dima1983 (14.04.11 22:15) [8]
Не хами, а то забанят.
Хорошие спецы всегда вежливы. :)
← →
Кщд (2011-04-25 13:35) [12]>ANB (25.04.11 11:41) [10]
>В данном случае rowid проще и лучше PK.
чем?
← →
ANB (2011-04-25 14:18) [13]
> чем?
1) Быстрее
2) Не надо думать об алгоритме заполнения ПК.
← →
Ega23 © (2011-04-25 14:33) [14]
> 2) Не надо думать об алгоритме заполнения ПК.
Тебе и так о нём не надо думать.
А ещё ПК индексируется.
← →
Petr V. Abramov © (2011-04-25 22:08) [15]
> Ведь до 8 клиента передавались же как-то BLOB в хранимые
> процедуры?
до 8-го что клиента, что сервера, не было BLOB, были log raw.
а оно уже не поддерживается лет дцать
← →
ANB (2011-04-26 16:54) [16]> Тебе и так о нём не надо думать.
Это как ? Автоинкрементов в оракле нету
> А ещё ПК индексируется.
А rowid индекс вообще не нужен
← →
Ega23 © (2011-04-26 17:17) [17]
> Это как ? Автоинкрементов в оракле нету
Сиквенсов в оракле тоже нету?
← →
Игорь Шевченко © (2011-04-26 21:48) [18]еще надо реактор на субтепловых нейтронах приделать
← →
ANB (2011-04-27 12:56) [19]
> еще надо реактор на субтепловых нейтронах приделать
+1.
Зачем извращаться и плодить кучу объектов для тупого обходного маневра по передаче параметра ?
Это ВРЕМЯНКА !!! Зачем ей ПК и сиквенс ???
← →
Кщд (2011-04-27 15:06) [20]>ANB (27.04.11 12:56) [19]
было предложено gtt on commit delete rows
автору по неведомой причине не подошло
коли вариант отвергнут и PK создавать не хочется, то я бы подумал о том, что, запомнив PK при вставке, запись гарантированно можно удалить по этому значению PK. при фиксировании rowid при вставке, такой гарантии нет.
← →
Игорь Шевченко © (2011-04-27 18:57) [21]Кщд (27.04.11 15:06) [20]
"Oracle guarantees that as long as the row exists, its rowid does not change. These performance and stability qualities make rowids useful for applications that select a set of rows, perform some operations on them, and then access some of the selected rows again, perhaps with the purpose of updating them"
http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/datatype.htm#i6732
← →
Кщд (2011-04-28 07:27) [22]>Игорь Шевченко © (27.04.11 18:57) [21]
Ляп в документации?
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:53140678334596
← →
Игорь Шевченко © (2011-04-28 11:44) [23]Кщд (28.04.11 07:27) [22]
> Ляп в документации?
нет.
"A rowid is assigned to a row upon insert and is imutable (never changing) unless the row
is deleted and re-inserted (meaning it is another row, not the same row!)"
все остальные случаи, упоминаемые Кайтом, относятся скорее к хранению rowid.
← →
Игорь Шевченко © (2011-04-28 17:43) [24]разумеется, если страховаться от того, что между получением ROWID и его использованием над целевой таблицей будет выполнено неопределенное число DDL, то таки да, первичный ключ надежнее. Но медленнее.
← →
Кщд (2011-04-29 12:11) [25]>Игорь Шевченко © (28.04.11 11:44) [23]
Да, насчет ляпа поспешил.
Кайт говорит о неявных insert/delete.
первичный ключ надежнее. Но медленнее.
поэтому и предлагает в предикате использовать и то(rowid), и другое(PK) - это быстро и надежно.
но, согласитесь, при наличии всего одной записи в таблице проигрыш при использовании только PK будет малосущественным
спасибо, что ткнули в доку, - познавательно
← →
Игорь Шевченко © (2011-04-29 13:25) [26]
> при наличии всего одной записи в таблице
достаточно SELECT без WHERE ;)
← →
Кщд (2011-04-29 15:13) [27]ага)
но очень не удивлюсь что при таком подходе, как у ТС, всё же будет больше одной записи)
я всё равно за одновременную скорость и надежность, т.е. rowid + PK
← →
Игорь Шевченко © (2011-04-29 17:30) [28]
> я всё равно за одновременную скорость и надежность, т.е.
> rowid + PK
Если не затруднит, приведёте пример для ситуации ТС, когда ему rowid будет недостаточно ?
Я напомню:
"1) Создаете табличку в БД с полем BLOB
2) Делаете в неё insert (без использования временного LOB локатора)
3) А в процедуру передаете RowId, главное потом не забыть удалить в процедуре после считывания ненужную строчку"
← →
Кщд (2011-04-29 19:44) [29]>Игорь Шевченко © (29.04.11 17:30) [28]
спорить не буду)
если бы пришлось выбирать между вариантом, который работает в любых случаях, и тем, который может не сработать при определенных условиях - мой выбор первый из них
а плюс один PK Oracle как-нибудь переживет)
это моё сокровенное имхо))
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2015.05.03;
Скачать: [xml.tar.bz2];
Память: 0.52 MB
Время: 0.002 c