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

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

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

Вставка записей в 2 таблицы [D5, MSSQL, ]

Страницы: 1 2 3 >
Shoo © (2001-12-13 13:20:00)
Мастера, интересует такая вещь: имею БД на MS SQL 7.0, использую ADO, имеется 2 таблицы, KatNakl и SpNakl, связанные таким образом: SpNakl.cNakl -> KatNakl.NRec. По нажатию кнопки хочу добавить данные в обе таблицы, у TADOQuery использую свойство SQL для формирования запроса на добавление и метод ExecSQL для выполнения запроса, примерно так:

procedure TForm1.Button1Click(Sender: TObject);
var mycNakl: longint;
begin
mycNakl := 0;
ADOQuery1.SQL.Clear;
with ADOQuery1.SQL do
begin
Add("insert into katnakl (datenakl, smena, priznak)");
Add("values (""10.12.2001"", 1, ""1"")");
end;
ADOQuery1.ExecSQL;

//как здесь получить новое значение поля NRec в KatNakl,
//записав его, скажем в mycNakl,
//чтобы подставить его в cNakl таблицы SpNakl?

ADOQuery1.SQL.Clear;
with ADOQuery1.SQL do
begin
Add("insert into spnakl (cnakl, name)");
Add("values (" + IntToStr(mycNakl) + ", ""QQQQQQQ""");
end;
ADOQuery1.ExecSQL;
end;
end;

И вообще, правильным ли путем я иду? Как лучше вставлять данные в моем случае? Заранее благодарен.

NewComer (2001-12-13 17:27:00) [1]
Предлагаю закрыть этот вопрос.
Не... И все-таки я не понял почему ты высказал эту фразу "в борьбе за отказ от "однопользовательского" мышления , так же, предлягаю отказаться от транзакций, и прочих прежитков "тяжёлого прошлого" вроде блокировак, а ещё ролей , пользователей и технологии "клиент-сервер""

Delirium (2001-12-13 17:26:00) [2]
В timestamp гарантированая уникальность только в составе одной машины!
И это лишает его права быть глобальным идентификатором. И вообще это всё уже давно флейм - жизнь нас рассудит :)

neXt (2001-12-13 17:21:00) [3]
timestamp нормально подходит на роль ключа уж во всяком случае ни чем не хуже guid"а я не защищаю его, только как альтернатива, а сточки зрения разработчика эти типы вообще отличаются только алгоритмом генерации и размером

NewComer (2001-12-13 17:15:00) [4]
Ой.. насчет timestamp я погарячился..... :-)

neXt (2001-12-13 17:15:00) [5]
в борьбе за отказ от "однопользовательского" мышления , так же, предлягаю отказаться от транзакций, и прочих прежитков "тяжёлого прошлого" вроде блокировак, а ещё ролей , пользователей и технологии "клиент-сервер"

NewComer (2001-12-13 17:13:00) [6]
timestamp - вообще специфичная штука, и не имеет никакого отношения к uniqueidentifier, тем более этот тип нельзя использовать для ключей.

Delirium (2001-12-13 17:12:00) [7]
"чем тогда GUID лучше timestamp тоже не с чем не совместим и индексируется на зашибись" - вернёмся к удалённым серверам :)

Delirium (2001-12-13 17:10:00) [8]
Это изначально "кривой" метод и естесвенно, прямо реализовать его с uniqueidentifier не получится, однако есть же триггера :)

neXt (2001-12-13 17:10:00) [9]
или тоже устаревший подход

neXt (2001-12-13 17:09:00) [10]
не ну чем тогда GUID лучше timestamp тоже не с чем не совместим и индексируется на зашибись

neXt (2001-12-13 17:08:00) [11]
выше: "вынужден"

NewComer (2001-12-13 17:07:00) [12]
"1.прошёл инсерт
2.в max(ID) мой только что внесённый ID-шник
удобно, особенно если инсерт - это процедура откуда ID ещё надо тянуть"
Необходимо отучаться от "однопользователького" метода мышления. ГЫ

neXt (2001-12-13 17:07:00) [13]
не не сдамся, я не вынужден писать не на одном MSSQL и выгрузка скажем в text или чего доброго в Sybase для полей GUID оборачивается серьёзным геморроем

NewComer (2001-12-13 17:05:00) [14]
select @ID = isnull(ID ,{00000000-0000-0000-0000-000000000000})
кстати сие выражени попахивает потенциальной ошибкой. ГЫ.

neXt (2001-12-13 17:03:00) [15]

Совсем упустил из виду "последовательность заполнения таблицы" это нонсенс, по идентификаторам определять прорядок занесения информации!

речь не о сортировке или явного определения последовательности, а вот о чем
при работе со временными таблицами (или с разбитыми по @@spid)
1.прошёл инсерт
2.в max(ID) мой только что внесённый ID-шник
удобно, особенно если инсерт - это процедура откуда ID ещё надо тянуть

Delirium (2001-12-13 17:01:00) [16]
На самом деле можно просто:
Declare @I uniqueidentifier select @I=null

NewComer (2001-12-13 17:00:00) [17]
NeXt! сдавайся! :-)))))
очень много аргументов в Пользу Guid. И вообще.. каждый пишет так, как ему удобней. Но сдаеться мне, что корни identity растут с аксесса, с однопользовательской системы.

neXt (2001-12-13 16:56:00) [18]
чесно говоря, рассматривая выражения вида
select @ID = isnull(ID ,{00000000-0000-0000-0000-000000000000})
и
select @ID = isnull(ID ,0)
моё предпочтение остаётся со старым добрым numeric или int

neXt (2001-12-13 16:53:00) [19]
значение null принемет не поле а переменная, например
select @ID = ID from ...
если там нет не одной пожходящей записи

Delirium (2001-12-13 16:47:00) [20]
Совсем упустил из виду "последовательность заполнения таблицы" это нонсенс, по идентификаторам определять прорядок занесения информации!

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

Наверх

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