Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 8 9 10 11 12 [13] 14 15 16 17 .. 23   вперед  Ctrl
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
AAron
Меня раздражает в Оракле то, что вносимымые разработчиками некоей системы изменения "рушат" стыковую область, ибо они забывают рекомпилировать все задействованные объекты - проблемы этих разработчиков, но никак не Оракла


То что Oracle ПОКАЗЫВАЕТ нарушенные зависимости сразу после внесения изменений, а не через год экспуатации - скорее плюс чем минус IMHO разумеется. Если разработчики НЕ ЗНАЮТ, что разрушенные объекты необходимо перекомпилировать или забывают об этом - гнать вшею таких разработчиков.
29 янв 07, 13:48    [3707324]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Gluk (Kazan)

Напоминаю, в Oracle ЛЮБОЙ запрос есть КУРСОР, вне зависимости от того как он оформлен


Возможно здесь и порылась собака. В MS SQL есть понятие резалтсет. Он может быть сформирован:

1. Запросом с клиента.
2. Вызовом хп, содержащей запрос.
3. FETCHем из курсора.

Причем для обычного курсора (а не для курсоров, поддерживаемыми системными хп) каждый FETCH будет порождать резалтсет. Естественно, имеется в виду FETCH не в переменные.
29 янв 07, 13:54    [3707371]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
pkarklin
Возможно здесь и порылась собака.


Вероятнее всего так. В Oracle ResultSet это ни что иное как открытый курсор. Такой же как и все остальные. Это не повод ставить минус какой либо из СУБД
29 янв 07, 13:57    [3707401]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Gluk (Kazan)

Вероятнее всего так. В Oracle ResultSet это ни что иное как открытый курсор. Такой же как и все остальные. Это не повод ставить минус какой либо из СУБД


Ну не за это же я минус поставил, что у нас resultset а у вас открытый курсор. :( Пусть он хоть чертом называется, лишь бы его использование было прозрачным, чтов хп, что в не ее.
29 янв 07, 14:01    [3707431]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
pkarklin
Я все-таки "-" Oracle поставлю. Именно за ту неоднозначость в поведении инструций в теле хп и вне ее. У этой фичи есть один большой плюс - ее прозрачность, т.е. переход от прямых запросов с клиента к хп не вызывает изменения в подходах к работе.


Честно говоря не понял о какой "неоднозначности" у Oracle тут идет речь. По моему именно в MSSQL нет "однозначности" - никогда не известно, что именно вернет вызываемая процедура.
Для меня, например, просто дико видеть прораммный код, который делает какой-то возврат в "никуда" без явного объявления возвращаемого значения. Может быть это все из-за привычки работать со строго типизированными языками? Но мне всегда хотелось быть уверенным, что вызывая какой-то программный объект я получу от него результат соответствующий спецификации этого объекта. Если я выполняю select-запрос, то его спецификация "заключена" в select-list, если я вызываю процедуру, то ее спецификация - описание параметров. И в том и в другом случае спецификация доступна без исполнения программного кода. Ну а в случае MSSQL запроса внутри процедуры оказывается, что спецификация процедуры находится внутри исполняемого кода и получить ее не выполнив процедуру - нельзя.
29 янв 07, 14:17    [3707521]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Bogdanov Andrey
По моему именно в MSSQL нет "однозначности" - никогда не известно, что именно вернет вызываемая процедура.

Для меня, например, просто дико видеть прораммный код, который делает какой-то возврат в "никуда" без явного объявления возвращаемого значения.
...
Если я выполняю select-запрос, то его спецификация "заключена" в select-list, если я вызываю процедуру, то ее спецификация - описание параметров.


Гм... Скажите, пожалуйста, что для Вас неоднозначно в этом коде:

CREATE PROCEDURE au_info_all
AS
SELECT au_lname, au_fname, title, pub_name
   FROM authors a INNER JOIN titleauthor ta
      ON a.au_id = ta.au_id INNER JOIN titles t
      ON t.title_id = ta.title_id INNER JOIN publishers p
      ON t.pub_id = p.pub_id
GO

Чем он для Вас неодназначен по сравнению с просто запросом:

SELECT au_lname, au_fname, title, pub_name
   FROM authors a INNER JOIN titleauthor ta
      ON a.au_id = ta.au_id INNER JOIN titles t
      ON t.title_id = ta.title_id INNER JOIN publishers p
      ON t.pub_id = p.pub_id

В обоих случаях "спецификация "заключена" в select-list"


???
29 янв 07, 14:24    [3707564]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Извините, поторопился кнопку нажать.

pkarklin
Ну а в случае MSSQL запроса внутри процедуры оказывается, что спецификация процедуры находится внутри исполняемого кода и получить ее не выполнив процедуру - нельзя.


А что, спецификацию запроса можно получить не выполнив его? В MS SQL есть следующая SET опция - SET FMTONLY ON . Если ее установить то в результате выполнения любой инструкции ни будет обработано ни одной записи, а будет возвращен пустой набор только из метаданных. Наверняка, что то похожее есть и в Oracle.
29 янв 07, 14:28    [3707591]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67393
Блог
pkarklin
Александр, я где-то сказал, что Oracle что-то "не умеет"?!

Да, безусловно, в https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=377674&pg=11#3699545

Надеюсь, на этом вопрос с "хорошей памятью" мы закроем :)

pkarklin
Возвращение курсора и возвращение набора данных, в моем понимании, это все-таки разные вещи.

Хм. Думаю, если Вы начнете копать, чем же они разные, раз за разом будете упираться в конкретные технические детали.

pkarklin
Хотя (на счет) прозрачности вспоминается удивление, которое вызывают у специалистов по Oracle на предмет хранимых процедур, содержащих только один SELECT. М.б. не так все уж и просто с ref-курсорами?!

Эээ.... этот образец Вашей логики вызвал просто умиление. Давайте смотреть. С точки зрения любого "обычного" программиста, то есть - не знакомого специально с этой фичой, возврат набора данных в результате SELECT - крайне неочевидный побочный эффект. Думаю, Вы согласитесь, что есть взять не знающего SQL программиста и показать ему "подпрограмму из одного SELECT", он в жизни не догадается, что оказывается она что-то возвращает. Если же показать ему аналогичную подпрограмму на PL/SQL - догадается, синтаксис там вполне традиционный.

Таким образом, удивление уже имеет почву под ногами. Теперь, если взять Oracle-программистов, опять же не знакомых с этим побочным эффектом, они прочитают код примерно так: "делаем запрос, его результат игнорируем". И я вполне понимаю удивление "ну и нафига такое надо?".

И вот Вы совершенно мистическим образом выводите из этого удивления "все не так просто с ref cursor". Всего лишь оттого, что в Oracle аналогичные по результату операции делаются явно и недвусмысленно.

pkarklin
Мне не совсем понятно, о каких недостатках Вы говорите:

Хм. Могу повторить еще раз. О том, что:

- сделанные выборки не входят в описанный и проверяемый компилятором интерфейс ХП
- выборки возвращаются неявно и доступны только через индекс (порядковый номер) в массиве возвращаемых рекордсетов
- порядковый номер конкретного рекордсета может измениться в результате внутренних изменений в ХП, причем замечено это будет не раньше, чем куда-то лягут совсем не те данные, которые ожидались

pkarklin
Какой недостаток? С какими имеющимся?

Вообще жаль осознавать, что по моей ссылке Вы сходили не для того, чтобы прочитать написанное там.

pkarklin
Я всего-навсего констатировал факт того, что такая же прозрачная конструкция, как возвращение результата их хп SELECTом в Oracle отсутствует.

Во-первых, прозрачность этой конструкции является фактом только для Вас. Имхо для любого нормального программиста "прозрачным" является возвращение результата функции через "собственно результат" и out параметры.

Сказать по правде, даже принимая Ваше предположение о прозрачности такого подхода, я совершенно не готов сказать, чем должно закончиться выполнение такой простой и прозрачной конструкции, как например

create procedure ManyDigits as
  select * from [master].[dbo].[digits]
  select * from [master].[dbo].[digits]
  select * from [master].[dbo].[digits]
  select 1, 2, 3 from [master].[dbo].[digits]
go

create table #Temp (i int)

insert into #Temp exec [master].[dbo].[ManyDigits]

select * from #Temp

Итого - не вижу прозрачности, увы.

pkarklin
Но все равно, мне странно осознавать различность поведения "просто запроса с клиента" и "этого же запроса в теле хп".

Хм. Действительно, странно осознавать то, чего нет :) Я догадываюсь, что это заявление Вас.. взбаламутит, но пожалуйста, подумайте, прежде чем отвечать первым, что захочется сказать.

pkarklin
pkarklin
Единственный аргумент, который от Вас прозвучал - "повсеместно применим при работе с MSSQL".

Это действительно так - set-ориентированный подход, вместо навигационного.

См. выше про "я понимаю, Вам выгодно тянуть". Делается красивое лицо, легкий намер на то, что только MSSQL применяет прогрессивный set подход, и все - для задачи "передать выборку на клиента", которой этот set подход не то что глубоко по барабану, а скорее вреден (поскольку выборка идет целиком).

pkarklin
pkarklin
С моей точки зрения, это крайне слабый аргумент даже сам по себе, хотя для облегчения миграции с MSSQL на Oracle может быть и стоило бы сделать

Имеено то, что в Oracle "это не сделано" меня и не устроило. М.б. для Вас это и не является "сильным аргументом", для меня он таковым является.

"Вас не устроило по Вашим религиозным воззрениям" для меня действительно не является сильным аргументом. А с объективными традиционно напряг. После долгих попыток, в письме, на которое я отвечаю, наконец родился один: прозрачность. Я сомневаюсь в ее наличии, но при наличии согласился бы считать объективным аргументом.

pkarklin
softwarer
Пока что опять-таки получен один аргумент: ADO иначе не умеет.


Хм... Я рассказал, как можно использовать в MS SQL некий аналог ref-курсоров в Oracle. Вы спросили - можно ли такой способ использовать при работе с колмпонентом, требующим наличия закладок. Я сказал нет. Но ни коим образом не может являться недостатком описанного способа, ибо ни это есть его место применения.

Хм. "И он будет говорить, что у него хорошая память".

Во-первых, я не говорил про "работе с компонентом, требущим наличия закладок". Я собственно только от Вас услышал, что DBGrid их оказывается требует.

Во-вторых, каких-то пару страниц назад Вы говорили, что этот способ - позволяет возвращать данные на клиента. Я спросил: а можно ли с этими данными на клиенте нормально работать? Для чего привел первую, самую страндартную задачу: вывести их в грид (без дополнительных телодвижений). Вы говорите - нельзя, сейчас еще усиливаете: не для того, этот механизм.

Итого, Ваше утверждение получается таким: вернуть данные на клиента можно, а то, что там с ними ничего нельзя нормально сделать, придется извращаться, так это фигня. На этот раз я Вас правильно понял?

**************************************************************************

Ладно, хватит. Поставлю вопрос так, чтобы на него можно и нужно было бы ответить "да" или "нет". Итак:

- существует ли в MSSQL возможность передать выборку из серверной ХП на клиент, используя как механизм передачи параметры подпрограммы и работая на клиенте с полученной выборкой нормальным для дельфы образом?

pkarklin
Спасибо, с памятью у меня все в порядке. Я все-таки "-" Oracle поставлю. Именно за ту неоднозначость в поведении инструций в теле хп и вне ее.

Насчет памяти мы уже выяснили, насчет минуса... да собственно ставьте. Только пожалуйста тему соблюдайте, а то весело получается - "вот за это минус поставить не удалось, тогда придумаю что-нибудь другое, за что можно поставить".

Хотите сравнивать прозрачность - давайте сравнивать. Отдельным направлением беседы.

pkarklin
У этой фичи есть один большой плюс - ее прозрачность, т.е. переход от прямых запросов с клиента к хп не вызывает изменения в подходах к работе. Насколько, я понимаю, в Oracle это не так. И, мне кажеться, именно по этому среди разработчиков на Oracle так распространены запросы с клиентов.

Оо... талантливый переход. То есть от бытовавшего у Вас ранее тезиса о плохой производительности в MSSQL запросов с клиентов Вы непринужденно перешли к тому, что "ораклоиды" в силу якобы недостатков Oracle отклоняются в сторону от, видимо, оптимума.

Чтобы закончить тему прозрачности: операция перехода от запросов с клиента к ХП, если предположить что она зачем-то нужна, и там, и там делается прибавлением "до и после запроса" двух заранее определенных фрагментов текста. И там, и там, программисту говорится примерно следующее: вот шаблон, сюда подставляешь имя ХП, сюда подставляешь запрос, все. Чем одно более прозрачно, чем другое, затрудняюсь понять.

pkarklin
Вы немного извратили то, что я спрашивал.

Хм. Забавно видеть это ответом на тот абзац, где я напомнил, о чем мы собственно вообще беседуем.

pkarklin
Повторюсь еще раз.

Хм. Просмотрел последние страницы три, но так и не нашел, где Вы поднимали эту тему ранее этого письма.

pkarklin
Для чего было в Oracle было сделано различие между поведением запроса с клиента и этого же запроса в хп?

Как Вам сказать..... это бессмысленный вопрос, из серии "ты перестала пить коньяк по утрам"? На него можно ответить только объяснением того, что предпосылки, на которые он опирается, являются ложными.
29 янв 07, 14:33    [3707633]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
pkarklin


Гм... Скажите, пожалуйста, что для Вас неоднозначно в этом коде:

CREATE PROCEDURE au_info_all
AS
SELECT au_lname, au_fname, title, pub_name
   FROM authors a INNER JOIN titleauthor ta
      ON a.au_id = ta.au_id INNER JOIN titles t
      ON t.title_id = ta.title_id INNER JOIN publishers p
      ON t.pub_id = p.pub_id
GO

Чем он для Вас неодназначен по сравнению с просто запросом:

SELECT au_lname, au_fname, title, pub_name
   FROM authors a INNER JOIN titleauthor ta
      ON a.au_id = ta.au_id INNER JOIN titles t
      ON t.title_id = ta.title_id INNER JOIN publishers p
      ON t.pub_id = p.pub_id

В обоих случаях "спецификация "заключена" в select-list"

???


Правильно, спецификация заключена в select-list. Но это значит, что верхний пример не процедура, а просто sql-запрос (зачем-то обернутый в дополнительные слова "procedure" и п.т.)
Проблема в том, что я не могу для этой "так называемой процедуры" получить описание выходного массива данных.

pkarklin

А что, спецификацию запроса можно получить не выполнив его?

И даже очень легко. Правда я давненько с MSSQL не работал, но по-моему там тоже есть "parse".
29 янв 07, 14:51    [3707791]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
kennethr
Member

Откуда:
Сообщений: 175
pkarklin
И, мне кажеться, именно по этому среди разработчиков на Oracle так распространены запросы с клиентов.

В принципе в Oracle вы можете написать нечто подобное и использовать в DBGrid:
create or replace procedure P_TEST(rs out sys_refcursor) is
begin
  open rs for
    select *
      from some_table;
end;
Это ненамного сложнее MSSQL, но гораздо логичнее.
Почему многие так не делают? Не знаю. Лично у меня компоненты под запросы заточены. А раньше oracle старый был. Иногда просто дело привычки.
29 янв 07, 14:58    [3707837]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
kennethr
Почему многие так не делают? Не знаю.


1. Из за NDS
2. Из за звезды

Хотя вполне допускаю, что у Вас не та задача в которой за эти пункты отрывают яйца
29 янв 07, 15:05    [3707899]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
kennethr
create or replace procedure P_TEST(rs out sys_refcursor) is
begin
  open rs for
    select *
      from some_table;
end;


Если бы some_table было параметром, то было бы еще SQL Injection
29 янв 07, 15:07    [3707912]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Sorry, на NDS и Injection стойку сделал автоматически
не было их
29 янв 07, 15:09    [3707931]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
kennethr
Member

Откуда:
Сообщений: 175
Gluk (Kazan)
на NDS и Injection

Стыдно признаться, не понял терминов. Ссылкой киньте.
ЗЫ: Это был просто пример.
29 янв 07, 15:13    [3707976]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67393
Блог
kennethr
Почему многие так не делают? Не знаю. Лично у меня компоненты под запросы заточены. А раньше oracle старый был. Иногда просто дело привычки.

Хм. Такая техника работает кажется с 6-го Oracle, так что вряд ли стоит кивать на старину. Просто как правило это не нужно, в большинстве случаев лишняя прокладка.
29 янв 07, 15:14    [3707989]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67393
Блог
andy st
про OLE DB провайдер это сильно. особенно если оракул крутится под линухом или чем-нибудь еще более экзотичным.

Кстати... https://www.sql.ru/forum/actualthread.aspx?tid=389458
29 янв 07, 15:20    [3708042]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
kennethr
Gluk (Kazan)
на NDS и Injection

Стыдно признаться, не понял терминов. Ссылкой киньте.
ЗЫ: Это был просто пример.


NDS - это просто динамический SQL, в примере его нет, но был-бы будь там кавычки.
как минимум лишний парсинг, там где его быть не должно
Injection - засовывание в динамический SQL того, чего там никогда не было, например прицепленного union all-ом списка хешей паролей
29 янв 07, 15:26    [3708110]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
kennethr
Member

Откуда:
Сообщений: 175
softwarer

Человек хотел как в MSSQL, мне кажется очень похоже. А применение для такой формы вполне реальное, ограничение доступа к объектам. softwarer, это не вам :-)
29 янв 07, 15:27    [3708114]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
kennethr
Человек хотел как в MSSQL, мне кажется очень похоже. А применение для такой формы вполне реальное, ограничение доступа к объектам. softwarer, это не вам :-)


Для начала, человеку стоило задать вопрос, а ЗАЧЕМ ему нужно КАК в MS SQL ???
Это так, к вопросу о ШАШЕЧКАХ
29 янв 07, 15:32    [3708154]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
Да, безусловно, в https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=377674&pg=11#3699545

Надеюсь, на этом вопрос с "хорошей памятью" мы закроем :)


Ok. Признаю.

softwarer
С точки зрения любого "обычного" программиста, то есть - не знакомого специально с этой фичой, возврат набора данных в результате SELECT - крайне неочевидный побочный эффект.


Однако, очень смело с Вашей стороны за "всех" обычных программистов высказываться.

softwarer
Думаю, Вы согласитесь, что есть взять не знающего SQL программиста и показать ему "подпрограмму из одного SELECT", он в жизни не догадается, что оказывается она что-то возвращает. Если же показать ему аналогичную подпрограмму на PL/SQL - догадается, синтаксис там вполне традиционный.


Позволю себе с Вами не согласиться. С чего бы это "не знающему SQL программисту" надо различать:

CREAT VIEW ... AS SELECT... и CREATE PROC ... AS SELECT...? Почему в одном случаи SELECT что-то возвращает, а во втором он недолжен ничего возвращать. А еще болеше надо догадаться, что для того, чтобы что-то вернуть из CREATE PROC нужно знать синтаксис некоего PL\SQL, а не основы ANSI SQL.

softwarer
Таким образом, удивление уже имеет почву под ногами. Теперь, если взять Oracle-программистов, опять же не знакомых с этим побочным эффектом, они прочитают код примерно так: "делаем запрос, его результат игнорируем". И я вполне понимаю удивление "ну и нафига такое надо?".

И вот Вы совершенно мистическим образом выводите из этого удивления "все не так просто с ref cursor". Всего лишь оттого, что в Oracle аналогичные по результату операции делаются явно и недвусмысленно.


Хм... Я не делал вывод я спросил:

pkarklin
М.б. не так все уж и просто с ref-курсорами?!


И вопрос этот был навеян некоторыми высказываниями участников обсуждения:

Gluk (Kazan)
kennethr
Интерфейс на чем пишете?


Понял вопрос :) Я противник возврата ref-курсоров клиенту, поэтому выборки одиночными select-ами, ВЕСЬ DML только через вызовы процедур пакетов. На клиенте, разумеется эти вызовы оборачиваются в анонимный блок.


И это я слышу не первый раз. Так что же все-таки с реф-курсорами?

Про недостатки.

softwarer
- сделанные выборки не входят в описанный и проверяемый компилятором интерфейс ХП


Тут могу согласиться.

softwarer
- выборки возвращаются неявно и доступны только через индекс (порядковый номер) в массиве возвращаемых рекордсетов


Хотя существует возможность возвращать из хп более чем один резалтсет я противник такого подхода именно из-за приведенных Вами предыдущего и следующего недостатков.

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


softwarer
Во-первых, прозрачность этой конструкции является фактом только для Вас. Имхо для любого нормального программиста "прозрачным" является возвращение результата функции через "собственно результат" и out параметры.


Если возможности языка это позволяют, то почему бы не рассматривать это как дополнительную возможность, а не как "извращение"?

softwarer
Сказать по правде, даже принимая Ваше предположение о прозрачности такого подхода, я совершенно не готов сказать, чем должно закончиться выполнение такой простой и прозрачной конструкции, как например...


Зато я готов. Вы получите ошибку о не совпадении целевой таблицы и возвращаемого резалтсета по метаданным. Естественно в момент выполнения. Можно, конечно, еще более бездумный код написать, и рассуждать о его прозрачности.

softwarer
"передать выборку на клиента", которой этот set подход не то что глубоко по барабану, а скорее вреден (поскольку выборка идет целиком).


И почему выборка из 20 записей вредна клиенту?! Я же не заставляю тащить на клиента 1 000 000 записей.


softwarer
- существует ли в MSSQL возможность передать выборку из серверной ХП на клиент, используя как механизм передачи параметры подпрограммы и работая на клиенте с полученной выборкой нормальным для дельфы образом?


Нет.

softwarer
Как Вам сказать..... это бессмысленный вопрос, из серии "ты перестала пить коньяк по утрам"? На него можно ответить только объяснением того, что предпосылки, на которые он опирается, являются ложными.


Это не ответ.
29 янв 07, 15:48    [3708280]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
kennethr
А применение для такой формы вполне реальное, ограничение доступа к объектам.)


Я уже об этом не один раз говорил, правда не в этом топике. Хорошо, что хоть до Вас дошло. :)
29 янв 07, 15:51    [3708301]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
pkarklin
Gluk (Kazan)
kennethr
Интерфейс на чем пишете?


Понял вопрос :) Я противник возврата ref-курсоров клиенту, поэтому выборки одиночными select-ами, ВЕСЬ DML только через вызовы процедур пакетов. На клиенте, разумеется эти вызовы оборачиваются в анонимный блок.


И это я слышу не первый раз. Так что же все-таки с реф-курсорами?


Религиозные соображения
29 янв 07, 16:23    [3708639]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Gluk (Kazan)
Религиозные соображения


А если есть время и Вас не затруднит можно чуть по-подробнее? М.б. это будет ссылка на обсуждение этого вопроса на форуме по Oracle?
29 янв 07, 16:25    [3708662]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
pkarklin
Gluk (Kazan)
Религиозные соображения


А если есть время и Вас не затруднит можно чуть по-подробнее? М.б. это будет ссылка на обсуждение этого вопроса на форуме по Oracle?


Завтра скорее всего. Сейчас немного не до того.
29 янв 07, 16:29    [3708692]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Ок. Подожду. Как будет время.
29 янв 07, 16:31    [3708704]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 8 9 10 11 12 [13] 14 15 16 17 .. 23   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить