Можно завести еще одно поле для связи в DataWindow, а поле PK не трогать. Внутри DataWindow осуществлять связь master-detail по значениям второго поля, используя для новых записей отрицательную нумерацию (в базу естественно ничего не сохраняя из этого второго поля).
А при SELECT'е заполнять его значениями из PK, в этом случае никаких коллизий произойти просто не может.

gzПочти так же. Новых полей не использую - пишу отрицательные значения как раз в поле PK - а в событии UpdateStart() отрицательные значения заменяю на уникальные из SEQUENS-последовательности (Oracle)
Можно и так, но шанс словить ошибку при кодировании таким образом выше.

gzА каким образом ? Сколько лет ловим, пока сетка пустая. Если перестраховываться, то уж в меру ...
Допустим нужно будет откатиться, тогда это нужно тоже нужно учитывать при кодировании. Имееются ввиду ошибки программиста при реализации механизма на PB.

ASCRUS Откаты на SEQUENS и IDENTITY не влияют, так что ошибок не будет.
Не про те ошибки идет речь.
gzМожет быть, имеете ввиду просто "кривые ручки" программиста ?
Да, именно это я и пытался сказать :) Больше нюансов в реализации, а сл-но больше вероятность ошибки (программиста).

savosin_sergeyя имел ввиду порядок строк в таблице без order'а. то есть, добавили несколько новых записей, визуально они появились в конце datawindow, а после retrieve (=select col1, col2, ... from table1 where parent_id=xxx) -- некоторые записи могут своё место в DW изменить.. но я это не видел, передаю лишь слова.. и не могу понять, почему, ведь нет сортировки даже по первичному ключу..
Для любой реляционной операции порядок следования кортежей отношений никогда не определен.
В конкретном частном случае записи по запросу
будут возвращены в порядке следования ссылок на строки table1 в parent_id.
Или в порядке физического местоположения записей записей в таблице table1 (в зависимости от селективности условия parent_id).
Но это никто и никому не обязан. Допустим, все может измениться от числа процессоров в системе
savosin_sergey на сервере средства работы с identity (автогенератором числового первичного ключа) не понравились главному разработчику
И какие же альтернативы?

авторВот алгоритм генерации нового уникального значения, применяемый у нас (в классах, работающих со связанными DW).. Правда, эта функция немного переделанная (работает лишь с одной таблицей bu_extravalues, но, жумаю, смысл будет ясен.. Переменные gnv_appl.i_step и gnv_appl.i_spid заполняются при запуске приложения.
И в чем же преимущества? Абсолютно не гарантируется никакой уникальности сгенерированных значений. Что, у одного пользователя не может быть несколько connect'ов к базе? Что достигается в результате такого извращения? Это если у вас главный разработчик такое пишет...

savosin_sergeyНомер коннекшена (через который будет производиться insert) всегда уникальен, среди всех подключённых пользователей. У одного пользователя можут быт два коннекта, но с разными @@spid.
А если пользователь по два приложения запустит?
savosin_sergeyТак что коллизий не наблюдается
Это главное достоинство метода?

EstetsТаблица t_idgenerator имеет IDENTITY поле.
Таблица t_sites используется для разделения диапазона по разным серверам.
А почему не использовать для этого identity seed?

savosin_sergeyБудет два SQLCA и два разных номера соединений
А когда запустят по 4 копии, вот тут-то диапазоны и перекроются.
savosin_sergeyДа на самом деле (это относится к MsSqlServer2000) можно использовать признак identity у колонки в таблице (чтобы она автоматически увеличивала значение) + функцию SCOPE_IDENTITY() -- она возвращает последнее значение identity-колонки в таблице, в которой произощёл последний insert.
А чем более ранние версии SQL сервера не угодили. Вы описали принцип заполнения переменной @@IDENTITY, а она и раньше была.
savosin_sergeyЭто необходимое условие работы метода.
А в чем его преимущества?

savosin_sergey Так один пользователь считал @@identity (до сохранения), потом другой считал @@identity -- произойдёт совпадение. Можно считывать лишь после сохранения -- с тем, чтобы передать его подчинённым detail'ам..
За каким извините хреном считывать identity до сохранения? Оно вообще неизвестно что вернет.
savosin_sergeyДругое преимущество: если использовать автоинкремент, то после сохранения в DW не будет значения уникального поля -- для этого надо сделать retrieve. Если записей много в таблице, то делать retrieve после каждого insert'а -- долгова-то. В этом случае придётся считывать @@identity из базы и присваивать полю DW.. ну или ещё что-нибудь придумывать..
Пользователь редко вводит больше 10 записей не сохраняясь. Вы думаете 10 SELECT @@identity сильно просадят производительность?

savosin_sergey Хотя можно увеличить шаг до 1000... всё равно если для первичного ключа использовать integer, то 2 млрда / 1000 = 200 000 000 -- нашу систему это устраивает (максимальное наблюдаемое число проводок около 90 млн за год)
Т.е. ваша система расчитана на то, чтобы проработать чуть больше 2-х лет?
Кроме того, вы размениваете тривиальный запрос к переменной connect-а (@@identity) при сохранении (которое не всегда будет), на гарантированный запрос при добавлении строки в DataWindow к таблце, что гораздо более затратно.
Какие еще преимущества, как вам кажется, есть у этого метода? (пока видны одни недостатки).

savosin_sergeyУважаемый Марк, ну а когда его, @@identity считывать? не после же сохранения?
именно после
savosin_sergeyили я что-то не понимаю..
безусловно, при том, вам это уже несколько раз объясняли (в т.ч. в соседнем форуме).
savosin_sergeyесть операция dw.update(boolean, boolean), есть операция select @@identity into :iid;.. даже если select @@identity повесить в event updatestart() -- разве гарантируется, что действия в updatestart() выполнятся в той же транзакции, что и реальное сохранение DW?
Да гарантируется, если у вас там на обработке очередная чушь не написана. Транзакциями в PB управляете Вы сами. Если транзакция начата, то пока вы не сделаете commit или rollback все будет в рамках этой транзакции.
Кроме того, если указать для таблицы identity column, то вообще ничего делать не нужно! После вставки каждой строки PB сам запросит значение автоинкремента и запишет его в нужную колонку DW.
savosin_sergeyя имел ввиду retrieve DW целиком -- чтобы в неё, в DW, закачались значения автоинкрементного столбца (после dw.update()). И если в таблице много строк, то по-идее, retrieve будет проходить некотрое заметное время.. (даже если он один, общий для всех введённых записей)
И для чего после сохранения делать retrieve DW целиком, чтобы получить значения автоинкрементов? Их не так получают.
savosin_sergeyИзвините, не понял.. в любом случае надо строку к DW добавлять (вопрос лишь в заполнении или в не заполнении поля с первичным ключём.). И в любом случае после нажатия "Сохранить" придётся делать update. Где гарантированный запрос?
Следите внимательно, объясняю последний раз.
При добавлении пользователем строки в DataWindow вам всегда необходимо будет исполнить запрос типа select max(field) from table
Вам это будет необходимо сдезать до записи в таблицу . Этот запрос необходимо будет исполнять всегда при вставке, в отличае от select @@identity, который нужно исполнять только после успешного insert (а еще пользователь может нажать "отмена"), и второй запрос занимает в сотни раз меньше ресурсов, чем первый.
Так что Вам тоже необходимо два запроса к серверу для вставки строки. Первый на select, второй на insert. В случае автоинкремента - первый на insert, второй на select.
Понятно?

savosin_sergeyТоварищ, воздержитесь от грубых выражений. Я на вас не наезжал.
То, каким образом у вас автоинкрементное поле вычисляется иначе как чушью назвать сложно. Ну не привели вы ни одного аргумента, почему так сделано. Если все приложение написано в том же духе, то может быть и на сохранение там свой "улучшенный" алгоритм написан.
savosin_sergeyЭто сделано на updatestart() -- то есть, только при сохранении ввода пользователем.
Хорошо, тогда запросов получится столько же. Но в этом случаее вообще не понятно, зачем Вам значение ключа до сохранения, если все-равно оно вычисляется непосредственно перед процедурой сохранения. Т.е. два документа шапка-подвал в одном окне не сохраняя у вас ввести нельзя?

Понятия не имею, что Вы там сделали, но если создать DataWindow на основе этой таблицы по запросу

Указать Allow Updates, выбрать таблиуц bu_test, в updateable columns выбрать data, в unique и identity - id, то зайдя на вкладку preview, внеся пару строчек и сохраня в поле ID мы получим значения автоинкремента. И в программе точно также. Какая версия PB?
savosin_sergey В обоих случая нету значения identity-поля, как это утверждалось здесь.
К вашему случаю это не имеет ровно никакого отношения.
savosin_sergey Хотя бы из-за этого генерация id-поля вручную имеет право на жизнь, как работающий вариант.Но уж точно не Ваш вариант.
savosin_sergey Альтернатива считыванию @@identity до сохранения..СКОЛЬКО РАЗ МОЖНО ГОВОРИТЬ, ЧТО @@identity НУЖНО СЧИТЫВАТЬ ПОСЛЕ СОХРАНЕНИЯ!!!