(powerBuilder 9.01 + msSqlServer 2000)
 У нас на фирме написана библиотека, аналогичная PFC.. и вот, хочу обсудить одну довольно общую проблему : ввод документа, состоящего из нескольких окон, связанных master-detail (один-ко-многим). Например, счёт-фактура может состоять из
1. заголовка
2. списка позиций
3. перечня дополнительных свойств для каждой позиции
 Пользователь должен иметь возможность сначала ввести документ целиком (или даже ввести несколько документов), и только потом -- сохранить (или отменить ввод). Собственно проблема: чтобы привязать строки подчинённых окон к главным, необходимо знать значение Primary Key главного окна (и это до сохранения!). У нас на фирме было (давно) принято такое решение: отказаться от автогенерации Primary Key и генерировать значение уникального поля до вставки в таблицу (пересечения с данными, вводимыми другими пользователями, исключаются использованием при генерации функции SQL-сервера, возвращающей номер соединения, @@uuid) , а после ввода уже спокойно сохранять. Коллизии такой генерации PK пока (за три-четыре года эксплуатации) не встречались.

 Вопрос:
1. какие ещё алгоритмы ввода многооконных документов предложите?
2. как это реализовано в PFC (в этой библиотеке тоже ведь есть службы связи окон (спрашиваю потому, что сам я ещё не пользовался этой библиотекой)
3. какие есть недостатки предложенного здесь метода ввода документов -- с помощью генерации первичного ключа до вставки? (подробности генерации там же .

спасибо!

понятно, спасибо за примеры.
 а чем так генерация первичного ключа на сервере не нравится? Наши утверждают (я сам не пробовал), что если пользоваться генерацией ключа на сервере (сиквенсы, identity и что там в Sybase-вский СУБД?), то может измениться порядок строк после insert\retrieve, правда, я не понял, почему.

я имел ввиду порядок строк в таблице без order'а. то есть, добавили несколько новых записей, визуально они появились в конце datawindow, а после retrieve (=select col1, col2, ... from table1 where parent_id=xxx) -- некоторые записи могут своё место в DW изменить.. но я это не видел, передаю лишь слова.. и не могу понять, почему, ведь нет сортировки даже по первичному ключу..
 Хотя, на мой взгляд, причины генерации первичного ключа другие (нежели простое соблюдение порядка строк в DW):
1. возможность заполнять несколько master'ов с detail'ами внутри (привязка строк в detail'е до сохранения master'а).
2. на сервере средства работы с identity (автогенератором числового первичного ключа) не понравились главному разработчику (напр., потому что реализованы кривова-то или, там, требуют вызова хранимой процедуры)

 Как выяснилось, у нас именно второй случай. а при вводе нового master'а происходит тихое сохранение введённых dateil'ов для строки, потерявшей фокус ввода.

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

авторЧто, у одного пользователя не может быть несколько connect'ов к базе? Что достигается в результате такого извращения?
Номер коннекшена (через который будет производиться insert) всегда уникальен, среди всех подключённых пользователей. У одного пользователя можут быт два коннекта, но с разными @@spid. Так что коллизий не наблюдается (уже больше трёх лет фурычит в минфине, там пользователей около 100, данные вводят человек 5)

другими словами, у SQLCA всегда один коннект, и у него есть уникальный номер на сервере (среди всез поключений к серверу). Как этот номер узнать в oracle или в sybase-вских СУБД я не знаю. в MsSqlServer это переменная @@spid