forum.clarionlife.net

А где видно, что ключ первичный, об этом надо торжественно заявить!
И при создании записи первичный ключ не должен быть пустой строкой, иначе мы никогда не найдём эту запись

kreator писал(а): 10 Декабрь 2019, 9:32 Раз MS не даёт "before" триггеры, то должна работать "дефолтная схема"

Зачем нужны "before" триггеры при insert

, создайте как положено, а потом в after триггер измените как надо )

Yufil писал(а): 10 Декабрь 2019, 10:16 А где видно, что ключ первичный, об этом надо торжественно заявить!

morkovin привёл часть скрипта на создание таблицы. Неужели Вы сомневаетесь, что поле "mid" первичный, а поле "uid_fk" внешний ключ?

gopstop2007 писал(а): 10 Декабрь 2019, 11:00
kreator писал(а): 10 Декабрь 2019, 9:32 Раз MS не даёт "before" триггеры, то должна работать "дефолтная схема"
Зачем нужны "before" триггеры , создайте как положено, а потом в after триггер измените как надо )

Баттл? А как положено? Я соглашусь, при добавлении записи можно настроить поля по "дефолту". Как настроить при изменении? Типичный пример. Мне нужно записывать дату, время изменения. Не вести журнал изменений в отдельной таблице, а в этой же. В ФБ я сделаю так в before триггере:

Код: Выделить всё

new."datetime" = current_datetime

И всё. Какие манипуляции надо провести в MS SQL? Снова апдейтить эту же запись. Гемор какой-то.
А если мне нужно сравнить поля на "было/стало"? В ФБ:

Код: Выделить всё

if new."id_fk"<>old."id_fk"
  бла-бла-бла ;

В MS надо запросы сделать по таблицам Inserted и Deleted. Зачем столько движух? К триггеру "before" это не относится напрямую. Просто к отсутствию "before" триггера добавляется отсутствие псевдозаписей old и new.

kreator писал(а): 10 Декабрь 2019, 11:27
Код: Выделить всё
new."datetime" = current_datetime

не понял, а чем CURRENT_TIMESTAMP или NOW не подошло? триггер зачем?

А как без триггера? "Ручные" запросы на апдейт, как правило, не пользую. По возможности обхожусть стандартными вещами. К тому же я апологет переноса всего что возможно на сервер

.

kreator писал(а): 10 Декабрь 2019, 17:11А как без триггера? "Ручные" запросы на апдейт, как правило, не пользую. По возможности обхожусть стандартными вещами. К тому же я апологет переноса всего что возможно на сервер .

на стороне сервера, отлично, и я о том же

поле как timestamp не рассматривается?
Например, правда в Mysql:

Код: Выделить всё

CREATE TABLE `product` (
  `PROD_ID` int(11) NOT NULL AUTO_INCREMENT,
  ...	
  `DATE_UPD` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`PROD_ID`)

Вот в ФБ нет конструкции "default on update". В каких-то сценариях такая конструкция была бы полезна. Надо будет разработчиков попытать на этот счёт.

как то в конце 90-х попался шаблон от ковбоев про перенос приложения под sql из 5 шагов. В тот момент тестил мелкомягкую 7-ку. Пришлось кое-что допиливать в шаблон. Потом мучил эмбаркадеро еще разные вещи довнес. Периодически добавлялись создание view, обработка initial value, validity check, допиливание конверторов для переноса. Однобокая такая заточка под переезд на мелкомягкий sql. Если кого еще интересует эта тема - могу закинуть

Если надо генерить GUID на сервере, то и генери, но просто вытаскивай его отдельно типа select newid() и записывай в поле первичного ключа в эмвэдэ "FieldPriming on Insert". Все будет работать в штатном режиме.

Rimas писал(а): 21 Декабрь 2019, 11:41Если надо генерить GUID на сервере, то и генери, но просто вытаскивай его отдельно типа select newid()

если идет речь о мелкомягких, то я бы лучше оринтировался на Scope_Identity()

forum.clarionlife.net

file{Prop:SQL}='INSERT INTO...'

file{Prop:SQL}='INSERT INTO...'

file{Prop:SQL}='INSERT INTO...'

file{Prop:SQL}='INSERT INTO...'

file{Prop:SQL}='INSERT INTO...'

file{Prop:SQL}='INSERT INTO...'

file{Prop:SQL}='INSERT INTO...'

file{Prop:SQL}='INSERT INTO...'

file{Prop:SQL}='INSERT INTO...'

file{Prop:SQL}='INSERT INTO...'

file{Prop:SQL}='INSERT INTO...'

file{Prop:SQL}='INSERT INTO...'