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() -- то есть, только при сохранении ввода пользователем.
Хорошо, тогда запросов получится столько же. Но в этом случаее вообще не понятно, зачем Вам значение ключа до сохранения, если все-равно оно вычисляется непосредственно перед процедурой сохранения. Т.е. два документа шапка-подвал в одном окне не сохраняя у вас ввести нельзя?