Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: 1 2 3 >
Mitrofan © (2004-05-13 09:22:00)
Скажите, имеется ли в MSSQL 2000 механизм автоинкремента или генераторы ? Как в данной СУБД для поля организовать уникальность значений ? Спасибо.

Курдль (2004-05-14 16:30:00) [1]

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

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

Zz_ (2004-05-14 16:24:00) [2]
Как вы думаете скока будет count(sp_xxx), для которых

sp_xxx cannot be used inside a user-defined transaction

Курдль (2004-05-14 15:53:00) [3]

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

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

bushmen (2004-05-14 15:48:00) [4]
>Для компонента типа TStopedProc, или обычного TQuery, >содержащего код вызова SP, транзакция открывается, закрывается >и откатывается автоматически по методу Execute (ExecSQL, >ExecProc).

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

-=VaaL=- (2004-05-14 15:42:00) [5]
Судя по всему нехватает генератора для полного счастья автора.
Ну дык можно самому чтонить замутить самостоятельно... на примере 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')

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

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

Курдль (2004-05-14 15:28:00) [6]

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

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

Zz_ (2004-05-14 15:24:00) [7]
>> "облегченное программирование"

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

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

Skyle (2004-05-14 15:21:00) [8]

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

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

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

> по ApplyUpdates.

:-)))

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

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

Курдль (2004-05-14 15:19:00) [9]

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

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

Курдль (2004-05-14 15:18:00) [10]
Может мы об одном и том же.

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

bushmen (2004-05-14 15:12:00) [11]
> Вот я его и обретаю!

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

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

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

Skyle (2004-05-14 15:09:00) [12]

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

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

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

Курдль (2004-05-14 15:05:00) [13]

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

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

Skyle (2004-05-14 15:02:00) [14]

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

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

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

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

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

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

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

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

Курдль (2004-05-14 14:54:00) [16]

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

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

bushmen (2004-05-14 14:54:00) [17]
> + все вытекающие

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

Skyle (2004-05-14 14:54:00) [18]

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

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

paul_k (2004-05-14 14:54:00) [19]
2Курдль ©
А как же в ХП и без оной? неаккуратненько как-то может получится...

bushmen (2004-05-14 14:49:00) [20]
>А это к какой таблице(полю/генератору/последовательности)относится?

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

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »