Уникальные значения в MSSQL 2000

← →
Курдль © (2004-05-14 14:54) [40]

> Если Вам это интересно, то на www.sql.ru обсуждался этот
> вопрос.

Да я так - чисто умозрительно! А мало ли где этот вопрос обсуждался?! Я Вас уверяю, что даже на этом форуме все вопросы где-нибудь да обсуждались!
Так что мы имеем? Иначе, чем специально обученной процедурой, идентити из MSSQL не вытянуть?

← →
bushmen © (2004-05-14 14:54) [41]

> + все вытекающие

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

← →
Skyle © (2004-05-14 14:54) [42]

> Но это значит, что надо насильственно открывать транзакцию
> + все вытекающие...

Выполнение батча в транзакции - имхо самое правильное поведение. И явно здесь открывать ничего не обязательно.

← →
paul_k © (2004-05-14 14:54) [43]

2Курдль ©
А как же в ХП и без оной? неаккуратненько как-то может получится...

← →
Курдль © (2004-05-14 15:00) [44]

> если нет у Вас опыта работы с MS SQL, то сначала преобретите,
> а потом спорьте.

Вот я его и обретаю!

> Выполнение батча в транзакции - имхо самое правильное поведение.
> И явно здесь открывать ничего не обязательно.

BEGIN TRAN [33] - это явно.
Но ладно. Возможность есть - и хорошо. Плохо, что ноа затрудняет "облегченное программирование" средствами, например, компонентов типа UpdateObject, имеющими в дизайн-тайме возможности автогенерации скриптов...

← →
Skyle © (2004-05-14 15:02) [45]

> BEGIN TRAN [33] - это явно.

...указывает на то, что

> Выполнение батча в транзакции - имхо самое правильное поведение

← →
Курдль © (2004-05-14 15:05) [46]

> > Выполнение батча в транзакции - имхо самое правильное
> поведение

Но это вовсе не значит, что открытие транзакции внутри ХП (скрипта) - хороший стиль.

← →
Skyle © (2004-05-14 15:09) [47]

> Но это вовсе не значит, что открытие транзакции внутри ХП
> (скрипта) - хороший стиль

Мне кажется, что стилем это можно назвать с большой натяжкой. Честно. Господина Дейта почитываем? Он там много про это рассуждает.

Я надеюсь, не стоит объяснять необходимость транзакции как таковой, особенно в примере
> Курдль © (14.05.04 14:30) [29]
?

← →
bushmen © (2004-05-14 15:12) [48]

> Вот я его и обретаю!

Странным образом Вы его преобретаете. Сначала говорите, что в MS SQL все организовано не правильно, а только потом изучаете :))

>Но это вовсе не значит, что открытие транзакции внутри ХП
>(скрипта) - хороший стиль

По-моему, опять пошла пустая болтовня. Только вот интересно каким образом в хранимой процедуре Вы обойдетесь без открытия транзакции? Тут нет Вашего любимого ApplyUpdate

← →
Курдль © (2004-05-14 15:18) [49]

Может мы об одном и том же.

В примере [29] я показал самое типичное окно из всех проектов.
Редко бывает такое счастье, что форма ввода работает только с одной таблицей. Но программирование такой формы проходит "на автомате" - методичным заполнением (а чаще - автозаполнением) запросов. Транзакции, естественно, отрабатываются но неявно - по ApplyUpdates.

← →
Курдль © (2004-05-14 15:19) [50]

> По-моему, опять пошла пустая болтовня. Только вот интересно
> каким образом в хранимой процедуре Вы обойдетесь без открытия
> транзакции? Тут нет Вашего любимого ApplyUpdate

А зачем ее открывать в ХП? В крайнем случае можно обойтись savepoint-ом.

← →
Skyle © (2004-05-14 15:21) [51]

> bushmen © (14.05.04 15:12) [48]

> Тут нет Вашего любимого ApplyUpdate

> Курдль © (14.05.04 15:18) [49]

> по ApplyUpdates.

:-)))

Я же говорил, что совсем не обязательно это делать ручками.
Плюс к тому, есть альтернативные архитектуры, где можно, лучше всего и самое удобное делать так, а не через ApplyUpdates.

Ладно, думаю пока заканчивать. Всё равно автор вопроса так и не появился...

← →
Zz_ (2004-05-14 15:24) [52]

>>"облегченное программирование"

Спорить с такими - совершенно бесполезно

Все эти компоненты разом дохнут, если, например,
есть жесткое требование - никаких прав ни на один объект
БД, окромя SP

> Все эти компоненты разом дохнут, если, например,
> есть жесткое требование - никаких прав ни на один объект
> БД, окромя SP

Ну и что из того? Если это к вопросу об открытии транзакции внутри SP, то все равно не оправдывается! Для компонента типа TStopedProc, или обычного TQuery, содержащего код вызова SP, транзакция открывается, закрывается и откатывается автоматически по методу Execute (ExecSQL, ExecProc).

Судя по всему нехватает генератора для полного счастья автора.
Ну дык можно самому чтонить замутить самостоятельно... на примере 2-ух таблиц

Вот для этой таблицы нам нужно создать генератор для первичного ключа
create table tab (t_id bigint primary key, t_value varchar(100))

А вот это таблица генератора:
create table gen
(g_id bigint identity(1,1) primary key,
g_guid uniqueidentifier)

припустим охота получить для себя 2 первичных ключа для tab не всталяя туда самих записей. Делаем так:

declare @g1 uniqueidentifier, @g2 uniqueidentifier
declare @p1 bigint, @p2 bigint

set @g1 = newid()
set @g2 = newid()
insert into gen values(@g1)
insert into gen values(@g2)
set @p1 = (select g_id from gen where g_guid = @g1)
set @p2 = (select g_id from gen where g_guid = @g2)
-- в @p1 и @p2 наши первичные ключи
delete from gen where g_guid = @g1
delete from gen where g_guid = @g2

-- вставка в таблицу проводится банально:

insert into tab values (@p1, "value1")
insert into tab values (@p2, "value1")

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

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

>Для компонента типа TStopedProc, или обычного TQuery, >содержащего код вызова SP, транзакция открывается, закрывается >и откатывается автоматически по методу Execute (ExecSQL, >ExecProc).

Вы сами это проверяли? По-моему, нет!

> Вы сами это проверяли? По-моему, нет!

Да ясен пень, что 1000 раз проверял! Даже может 100 000 000! Столько раз, сколько раз данные успешно попадали в БД!

← →
Zz_ (2004-05-14 16:24) [57]

Как вы думаете скока будет count(sp_xxx), для которых

sp_xxx cannot be used inside a user-defined transaction

> Как вы думаете скока будет count(sp_xxx), для которых
>
> sp_xxx cannot be used inside a user-defined transaction

Понятия не имею! А зачем ЭТО?

Уникальные значения в MSSQL 2000 Найти похожие ветки