Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8   вперед  Ctrl      все
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
Председатель Мао
а теперь представьте

Уважаемый, Вы пожалуйста сначала покажите свое решение, потом будем разбираться с другими Вашими... веселыми представлениями.
16 ноя 06, 13:27    [3408956]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
SergSuper
кстати вот пример недостатка оракловского null в строках по сравнению с ансишным

Да нет недостатка, просто я расписал этот фрагмент так, чтобы неоракловцы точно поняли, что имеется в виду. Реально там следовало бы использовать функцию nvl2 и результат был бы таким же, как у Вас.

Впрочем, это как раз наиболее неудачная особенность null-ов. Почему неудачная - приведу пример:

update SomeTable set field = field * :coeff

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

Yo.!!

Мне кажется, кто-то из нас двоих тормозит, и мне кажется, это не я.
16 ноя 06, 13:38    [3409029]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Yo.!!
Guest
softwarer

Мне кажется, кто-то из нас двоих тормозит, и мне кажется, это не я.

да, стормозил, мне показалось, что в начале был sql. а не динамический.

ЗЫ. а зачем nvl2, imho nvl вполне хватает ?
16 ноя 06, 13:47    [3409114]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
Yo.!!
imho nvl вполне хватает ?

Решение с nvl, которое я вижу, нравится мне меньше, чем использование nvl2.
16 ноя 06, 13:51    [3409165]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
Председатель Мао
а что в оракле нет isnull()?

Cкорее всего нет. Нафиг ему плохо названная нестандартная функция? В стандарте есть coalesce, которая удобнее и ораклового nvl, и mssql-ного isnull. На текущий момент я рекомендую своим использовать в коде именно coalesce.
16 ноя 06, 13:55    [3409189]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Председатель Мао
Member

Откуда:
Сообщений: 79
softwarer
Председатель Мао
а теперь представьте

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


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

Если это так, то такое же можно сделать в MSSQL,заводите юзера и даете ему грант на процедуру с селектом,а на прямой select не даете. Опять таки, если я правильно разобрался в вашем коде.
16 ноя 06, 14:17    [3409352]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
Председатель Мао
Если это так, то такое же можно сделать в MSSQL

Ну так сделайте, пожалуйста. Покажите код и результаты, полный скрипт, который любой может выполнить и увидеть. Напоминаю:

1. Есть два пользователя, t_app и t_user (или как угодно еще названные)
2. У пользователя t_app есть таблица
3. У пользователя t_app есть процедура, получающая строку фильтра и возвращающую выборку из таблицы, отфильтрованную указанным выражением
4. Пользователь t_user может вызвать процедуру и увидеть результаты
5. Пользователю t_user недоступен прямой select к таблице
16 ноя 06, 14:22    [3409383]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Председатель Мао
Member

Откуда:
Сообщений: 79
SergSuper
Председатель Мао
SergSuper
Председатель Мао
2 softwarer

а теперь представьте что ваше безобидная лишняя строчка open по свой сути применяет иной механизм выборки данных. То есть обычный селект будет намного быстрее работать, чем перебор строчек. А когда большой объем выборки, оракл скажет кря?

Не факт, это только домыслы


Так может давайте проверим?

А что проверять? И там и там процедуры выплёвывают данные клиенту. Почему должна быть разница?


Допустим у вас есть 6000 записей, вам нужно их вернуть. При селекте это будет одна итерация к серверу с 6000 строками, а при курсоре 6000 итераций по одной записи. Улавливаете разницу. Это конечно очень натянуто, но суть я думаю ясна.
16 ноя 06, 14:23    [3409392]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
Председатель Мао
Допустим у вас есть 6000 записей, вам нужно их вернуть. При селекте это будет одна итерация к серверу с 6000 строками, а при курсоре 6000 итераций по одной записи. Улавливаете разницу. Это конечно очень натянуто, но суть я думаю ясна.

Конечно, улавливаем. Допустим, мы хотим вывести эти данные в грид, показать пользователю. Вашей программе придется ждать, пока с сервера приедут все 6000 (или 60000. или 600000) записей. Моя запросит первые сто строк, покажет первые двадцать пять, и если пользователь не будет особо нажимать PgDn, оставшиеся никогда у сервера и не попросит. Если же мне потребуются все строки, например чтобы построить по ним какую-нибудь хитрую графику, я установлю FetchSize в миллион и опять же получу их "за одну итерацию".
16 ноя 06, 14:28    [3409443]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
softwarer
SergSuper
кстати вот пример недостатка оракловского null в строках по сравнению с ансишным

Да нет недостатка, просто я расписал этот фрагмент так, чтобы неоракловцы точно поняли, что имеется в виду. Реально там следовало бы использовать функцию nvl2 и результат был бы таким же, как у Вас.

Так точно же мне кажется не получится, но я думаю тут и так всё понятно
Хотя интересно посмотреть как это выглядит с nvl2 и nvl
softwarer

Впрочем, это как раз наиболее неудачная особенность null-ов. Почему неудачная - приведу пример:

update SomeTable set field = field * :coeff

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

Если поле не допускает нулов - то будет ошибка. Мне кажется наоборот удобно когда есть некая отдельная сущность.
А на самом деле это больше дело привычки.
16 ноя 06, 14:35    [3409512]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Председатель Мао
Member

Откуда:
Сообщений: 79
softwarer
Председатель Мао
Допустим у вас есть 6000 записей, вам нужно их вернуть. При селекте это будет одна итерация к серверу с 6000 строками, а при курсоре 6000 итераций по одной записи. Улавливаете разницу. Это конечно очень натянуто, но суть я думаю ясна.

Конечно, улавливаем. Допустим, мы хотим вывести эти данные в грид, показать пользователю. Вашей программе придется ждать, пока с сервера приедут все 6000 (или 60000. или 600000) записей. Моя запросит первые сто строк, покажет первые двадцать пять, и если пользователь не будет особо нажимать PgDn, оставшиеся никогда у сервера и не попросит. Если же мне потребуются все строки, например чтобы построить по ним какую-нибудь хитрую графику, я установлю FetchSize в миллион и опять же получу их "за одну итерацию".


Спорить не буду. Вы правы. Для прикладного применения принципиальной разницы нет. Конечному юзеру одновременно не нужно сразу 6000, элементарно на монитор не влезет. хватит и 100. Я просто сужу по MS, рекомендуется использовать курсоры, лишь тогда когда без них никак, а в оракл я так понял бегает по курсорам с крейсерской скоростью
16 ноя 06, 14:40    [3409565]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Yo.!!
Guest
SergSuper

Так точно же мне кажется не получится, но я думаю тут и так всё понятно
Хотя интересно посмотреть как это выглядит с nvl2 и nvl


SQL> set serveroutput on ;
SQL> declare
  2    filter varchar2(20);
  3    result sys_refcursor;
  4    tRec user_objects.object_name%type ;
  5  begin
  filter := NULL;
  7    open result for
        'select object_name from user_objects where rownum <= 5 ' || NVL(filter,'') ;
  9    fetch result into tRec;
      dbms_output.put_line(tRec);
 11  end;
 12  /
ZZZ_TYPE

PL/SQL procedure successfully completed.

SQL> declare
  2    filter varchar2(20);
  3    result sys_refcursor;
  4    tRec user_objects.object_name%type ;
  5  begin
  6    filter := 'and 1!=1';
  7    open result for
        'select object_name from user_objects where rownum <= 5 ' || NVL(filter,'') ;
  fetch result into tRec;
      dbms_output.put_line(tRec);
 11  end;
 12  /

PL/SQL procedure successfully completed.

куда nvl2 честно говоря и не знаю ...
16 ноя 06, 14:44    [3409615]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Yo.!!, достаточно было одной строчки
вобщем без ANDа фильтер не получается :)

а я почему-то считал что ISNULL - это ансишное, а COALESCE - это от SyBase...
16 ноя 06, 14:56    [3409734]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
SergSuper
Хотя интересно посмотреть как это выглядит с nvl2 и nvl


'select .... where rownum <= 5 ' || nvl2 ( filter, ' and ' || filter, null )

'select .... where rownum <= 5 and ' || nvl ( filter, '( 1 = 1 )' )

SergSuper
Если поле не допускает нулов - то будет ошибка.

Если не допускает, то будет ошибка. А если допускает?

SergSuper
Мне кажется наоборот удобно когда есть некая отдельная сущность.
А на самом деле это больше дело привычки.

Null как отдельная сущность - очень хорошая вещь. Это не дело привычки, поверьте, это дело соответствия инструмента задачам. Я работал над проектом, где было принято неиспользование null-ов, и насмотрелся на вытекающие из этого проблемы и ошибки, которые люди делали и делали несмотря на привычку.

Я целиком за null как отдельную сущность, но данную конкретную деталь его определения - "большинство операций с null дает результатом null" - я бы сделал иначе.
16 ноя 06, 15:26    [3410021]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32895

Привет, softwarer!
Ты пишешь:

softwarer
s> Я целиком за null как отдельную сущность, но данную конкретную деталь его определения -
s> "большинство операций с null дает результатом null" - я бы сделал иначе.
интересно об этом поговорить.
как именно иначе?

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

16 ноя 06, 15:28    [3410035]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
Мимопроходящий
как именно иначе?

Операции, в которых может участвовать null, можно разбить на три группы:

- те, в которых его участие осмысленно (is null, =, ||)
- те, в которых его участие [почти всегда] бессмысленно (скажем, арифметика)
- те, в которых вообще говоря бессмысленно, но сложно отфильтровать (скажем, агрегатные функции)

Куда отнести сравнение на меньше-больше - не уверен, интуитивно хочется во вторую группу, но есть ситуации, в которых будет уместна первая, так что скорее туда.

Так вот, первую и третью группы я бы оставил работать как сейчас, а во второй аргумент null считал бы ошибкой. Разумеется, все это строится на предположении о существовании "бессмысленных" операций. А это предположение - на том, что с ситуацией, где арифметика с участием null осмысленна, я не сталкивался.
16 ноя 06, 16:04    [3410331]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32895

Привет, softwarer!
Ты пишешь:

softwarer
s> - те, в которых его участие [почти всегда] бессмысленно (скажем, арифметика)
s> Так вот, первую и третью группы я бы оставил работать как сейчас, а во второй аргумент null считал бы ошибкой.
s> Разумеется, все это строится на предположении о существовании "бессмысленных" операций.
s> А это предположение - на том, что с ситуацией, где арифметика с участием null осмысленна, я не сталкивался.

ну а ныне, к примеру, стоимость = количество * цена,
если любой из операндов NULL, то результат NULL, вполне логичен.
ты предлагаешь генерить exception для таких случаёв?

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

16 ноя 06, 16:18    [3410438]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
softwarer

SergSuper
Если поле не допускает нулов - то будет ошибка.

Если не допускает, то будет ошибка. А если допускает?

А если поле допускает значение null, и в него таки записали null, пусть и по ошибке, по поводу чего СУБД возвращать ошибку? Если coeff окажется нулём -- тоже возвращать ошибку? А ведь данные пострадают немногим меньше.
16 ноя 06, 17:00    [3410790]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Председатель Мао
Member

Откуда:
Сообщений: 79
softwarer
Председатель Мао
Если это так, то такое же можно сделать в MSSQL

Ну так сделайте, пожалуйста. Покажите код и результаты, полный скрипт, который любой может выполнить и увидеть. Напоминаю:

1. Есть два пользователя, t_app и t_user (или как угодно еще названные)
2. У пользователя t_app есть таблица
3. У пользователя t_app есть процедура, получающая строку фильтра и возвращающую выборку из таблицы, отфильтрованную указанным выражением
4. Пользователь t_user может вызвать процедуру и увидеть результаты
5. Пользователю t_user недоступен прямой select к таблице


EXEC sp_addlogin 't_app'
EXEC sp_adduser 't_app'
EXEC sp_addlogin 't_user'
EXEC sp_adduser 't_user'

create table test(name_p varchar(255))
insert test(name_p)
values('sys1')
insert test(name_p)
values('sys2')
insert test(name_p)
values('sys3')
insert test(name_p)
values('non1')

create procedure test_p (@filter varchar(5))
as
begin
create table #t1(name_p varchar(100))
declare @sql varchar(200)
declare @name varchar(100)
 declare r cursor fast_forward for select name_p from test
 open r
 fetch r into @name
  while @@fetch_status!=-1
   begin
    if left(@name,3)=@filter
     begin
     set @sql='insert #t1(name_p) values('+char(39)+ @name+char(39)+')'
     exec (@sql)
     end
    fetch r into @name
  end
close r
deallocate r
select *from #t1
drop table #t1
end
grant select on test to t_app
grant exec on test_p to t_user
--заходим под t_app
select * from test where left(name_p,3)='sys'
sys1
sys2
sys3
 

--заходим под t_user
select * from test

Server: Msg 229, Level 14, State 5, Line 1
SELECT permission denied on object 'test', database 'Chocolate', owner 'dbo'.

exec test_p 'sys'

sys1
sys2
sys3
16 ноя 06, 17:09    [3410891]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Председатель Мао
Member

Откуда:
Сообщений: 79
Если не строить динамическую строку, а возвращать нормальный селект, то курсоры и прочее открывать не нужно. Все нормально отработает. Как вариант еще можно динамически в сессии законнектится под sa затем дать права на select, отработать select, забрать права, отконнектится как sa. Но лучше курсор. То есть mssql 2000, насчет 2005 не в курсе при построении в процедуре строки select, работает так же как будто бы он прямой. Но если в проц. записать прямой селект статический, то он будет нормально отрабатывать у юзера, у которго нет гранта на селект, но есть грант на процедуру.
16 ноя 06, 17:16    [3410962]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Председатель, ну чего изощряться то? Вопрос был в том можно ли в 2000-м запустить динамический запрос под правами создателя процедуры. Ответ: НЕТ. В 2005 можно.

Ну смешно же where вручную писать ( left(@name,3)=@filter). Мало ли чего нельзя, зачем рефлексировать - это же не говорит что без этого вообще невозможно
16 ноя 06, 17:32    [3411105]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Председатель Мао
Member

Откуда:
Сообщений: 79
SergSuper
Председатель, ну чего изощряться то? Вопрос был в том можно ли в 2000-м запустить динамический запрос под правами создателя процедуры. Ответ: НЕТ. В 2005 можно.

Ну смешно же where вручную писать ( left(@name,3)=@filter). Мало ли чего нельзя, зачем рефлексировать - это же не говорит что без этого вообще невозможно


Просто softwarer настаивал, чтобы ему привели код.
16 ноя 06, 17:39    [3411158]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
ChA
Member

Откуда: Москва
Сообщений: 11378
softwarer
Нет, не так. Точнее, я не имею личного опыта - не вижу никакого смысла использовать ODBC - но кого-то из спрашиваюших лично посылал в статью, где расписывалось, как использовать эту фичу через ODBC.
Посылать - дело нехитрое. Но что-то мне подсказывает, что реализация этой фичи даже если и возможна через ODBC, то сопровождается неоправданным геморроем в духе "мы это, конечно, сделать можем, но лучше не надо". ODBC не допускает асинхронной передачи данных, следовательно, эмуляция такой возможности будет более чем сложной при реализации и с весьма убогими результатами.
softwarer
Простуда здесь вызвана тем фактом, что клиентский код начинает неоправданно зависеть от реализации серверного.
Хмм, степень оправданности - вещь достаточно субъективная. Полагаю в Oracle тоже найдутся подобные казусы, но мы о них разумеется, говорить не будем.
softwarer
ChA
Но если правильно помню, то стандарт ODBC не поддерживает

Тем хуже для него. Я не понимаю, какой смысл кивать на кривой и мертвый стандарт и гордиться наследованием его глупостей.
Ну это всего лишь Ваше мнение, да и слухи о его смерти сильно преувеличены. IMHO, наличие любого общепринятого стандарта лучше, чем его отсутствие. Впрочем, знаком с Вашим пренебрежением к любым стандартам, включая законы ;) Хорошо, что это ограничивается только словами.
softwarer
Резюмируя: по сравнению с MSSQL, в Oracle для записи того же требуется одна лишняя строка (open for select вместо просто select). Этим мы покупаем именованные параметры-рекордсеты и возможность легко крутить выборки так, как нам удобно, в частности передавать их между подпрограммами и использовать на сервере.
Это только синтаксис, за которым скрывается мощный промежуточный слой, доступный клиентам фактически только через "родной" API.
А курсоры и в MSSQL можно передавать из вызываемой процедуры в вызывающую процедуру, только этим, как правило, никто не пользуется, так как принято работать с множествами, а не рекордсетами. Инструмент диктует правила владения им, топором забивать гвозди можно, но не так удобно, как молотком.
softwarer
Что касается второго из приведенных мной примеров, то подозреваю ответа на него я не дождусь
Если Вы про это, то с какого лешего Вы ждете ответа от меня ?
16 ноя 06, 17:41    [3411174]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
Председатель Мао

Ээ.... я бы отметил, что в постановке задачи говорится о фильтрации произвольным выражением, а не о передаче маски для конкретного поля.

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

Но я бы отметил именно тот факт, что в MSSQL при полноценном решении придется делать так, как делаете Вы - сначала динамическим sql с собственными правами наполнить временную таблицу, а потом статическим sql вернуть ее наружу. Эффективность этой конструкции.... не впечатляет, имхо.
16 ноя 06, 17:49    [3411236]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
ChA
Посылать - дело нехитрое

Хм.

ChA
Но что-то мне подсказывает

Это "что-то" - то же, что подсказывало ее невозможность?

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

Хм. Вообще-то весь ODBC - отлично вписывается в формулировку неоправданный геморрой в духе "мы это, конечно, сделать можем, но лучше не надо".

Сколь я помню ту статью, никакого дополнительного геморроя при этом нет. Cерверная процедура остается неизменной, в ODBC результат возвращается так же, как вернулся бы из аналогичной MSSQL-процедуры и выбирается тем же клиентским кодом.

ChA
Хмм, степень оправданности - вещь достаточно субъективная.

В общем случае - да. Тем не менее, зависимость интерфейса от реализации - повсеместно считается неоправданной.

ChA
Полагаю в Oracle тоже найдутся подобные казусы, но мы о них разумеется, говорить не будем.

Наверное, найдутся. Говорите, с интересом послушаю. Вон, председатель тоже был уверен в наличии казуса.

ChA
Ну это всего лишь Ваше мнение, да и слухи о его смерти сильно преувеличены.

Ну, "мнение" таки весомее "отмазок". Слухи же Вы легко можете развеять, если приведете внушительный список распространенного прикладного ПО, использующего ODBC как единственный либо основной интерфейс взаимодействия с БД.

Могу даже ограничить задачу: список ПО авторства Microsoft, использующего ODBC как единственный либо основной интерфейс.

Относительно ПО авторства Oracle и OCI - поверите на слово, что приведу такой список?

ChA
IMHO, наличие любого общепринятого стандарта лучше, чем его отсутствие.

Общепринятых стандартов в RDBMS нет. Что же до стандартов вообще - наличие хороших стандартов хорошо, наличие плохих стандартов плохо. Отсутствие стандартов - посередине.

ChA
Впрочем, знаком с Вашим пренебрежением к любым стандартам, включая законы ;) Хорошо, что это ограничивается только словами.

Поверхностное знакомство диктует поверхностные выводы.

ChA
А курсоры и в MSSQL можно передавать из вызываемой процедуры в вызывающую процедуру

Стоп. Курсоры или рекордсеты? Поясню: в описанном механизме Oracle я могу один и тот же курсор и использовать на сервере, и передать на клиента. То есть если есть хранимка, возвращающая выборку, я могу использовать эту выборку и на сервере, и на клиенте. Сколь я понимаю в MSSQL, тот явный курсор, который можно передать, и тот неявный рекордсет, который едет на клиента - разные вещи, "одной процедуры для обоих применений" сделать не удастся. Или я заблуждаюсь?

ChA
то с какого лешего Вы ждете ответа от меня ?

А кто Вам сказал, что я жду ответа от Вас? Эта фраза - часть резюме по сравнению.
16 ноя 06, 18:10    [3411414]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить