2 Филипп

>Тут на самом деле ещё один момент имеется.
Если у вас более менее примитивный интерфейс, то конечно autoincrement очень удобен, но если вы делаете какие нибудь сложные master/detail/linkage штучки, то нужно чтобы в рядах детальных datawindow уже имелись некие суррогатные ключи (чтобы их друг от друга отличать) ДО каких бы то ни было Updatов...

Даже в самом продвинутом интерфейсе остается необходимость заполнения таблиц с ключом типа автоинкремент, справочники например.

Похоже Вы были правы насчет макроподстановок в GetIdentity='Select max(IDENTCOL) from &TableName'. &TableName макроподставляется, а IDENTCOL - нет. Может нужно написать что-то вроде &identcol, но мне уже лень. Все мои DW смотрят на промежуточные view, а там мне никто не мешает первичный ключ назвать "id" для всех view и вписать его в запрос: 'Select max(id)...'. Это тоже работает, так что я вполне удовлетворен.

2 Локшин Марк

Не клевещите на PowerSoft, у них все продумано. :)

select max(...) это они предлагают использовать в тех SQL серверах, где нет переменной @@identity. В MSSQL как и в ASA @@identity есть, так что там можно использовать стандартный сайбейзовский механизм, вообще ничего не менять и проблем быть не должно.

В случае, если SQL сервер использует генераторы (oracle, firebird, postgresql, ...), то можно использовать что-то типа "GetIdentity='Select gen_id(&TableName,0) from RDB$DATABASE'" в PB.INI и тоже проблем не будет.

Более того, select max(id) тоже не приведет к проблемам. DW при сохранении новых строк работает ИМХО следующим образом: формируется и выполняется insert, вызывается select max(id)..., полученный id попадает в нужное поле DW и весь процесс повторяется для следующей строки. При этом id генерируется SQL сервером (иначе бы было не max(id), а max(id+1)), следовательно генерируется корректно и к конфликтам не приводит. Т.е. берется последний сгенерированный SQL сервером id. Поскольку пара insert-select всегда попадает в одноу транзакцию, то select max(id)... выберет "свой" id, даже если соседнее приложение в добавило строку в эту же таблицу во время между инсертом очередной строки и "select max(id)" для этой строки.

2 Локшин Марк

>Проблемы есть. Если работать в PB 6 с MS SQL через native интерфейс. Драйвер PowerSoft'а не знает о существовании @@identity и использует select max(...).

Возможно, никогда не работал в PB<->MSSQL, я рассуждал теоретически. 2 решения: 1) попробовать подправить pb.ini, по-моему там как то можно указать @@identity; 2) поставить более новый драйвер. Это прблема не PB а драйвера.

>На уровне изоляции транзакций serializable это, конечно, не приведет к проблемам при сохранении, зато такой уровень изоляции приведет к проблемам с пользователями :).

А какие проблемы с пользователями?

>А вот в реальной жизни к проблемам привести такая ситуация еще как может. Если в промежутке между insert/select в первой транзакции кто-то вставит запись в таблицу и сделает COMMIT, то select max(id) в первой транзакции вернет id от чужой строки.

Наверное в принципе такое возможно. Но commit гораздо длиннее insert/select, так что даже в этом случее должно быть правильно. Правда сильно зависит от реализации всего этого в конкретном SQL сервере. Конечно хорошим тоном будет не полагаться на такие вещи в реальном приложении. Ну так можно использовать что-то типа "GetIdentity='Select gen_id(&TableName,0) from RDB$DATABASE'" в PB.INI, оно работает корректно.

2 Механик

> В Oracle для этого есть Sequences.
А вообще проблемма-то в чём? Сотвори таблицу, куда максимальный ключ для таблицы пиши и всё.

Проблем с генерацией уникального ключа не было, была проблема чтения этого ключа из DW.

2 Локшин Марк

>Можно, но не в pb.ini и не в PB6.

Так поделитесь информацией.

>А насколько корректно он будет работать?

Не знаю, нужно пробовать.

>Native драйвера для доступа к базам данных вполне можно отнести к PB.

Можно отнести - нельзя отнести. Это уже пошел спор о словах. Если можно поставить новый драйвер не меняя версию PB и не меняя приложение, и это исправит ситуацию, то говорить не о чем, задача решена.

>Не в принципе, а возможно, и я с этим сталкивался.

Не спорю. Я не сталкивался.

>И чем же commit гораздо длиннее insert/select - поставить флажок в журнале, что транзакция подтверждена - это долго?

А еще нужно сделать все данные доступными для всех пользователей, а этих данных обычно немало, по крайней мере гораздо больше чем участвует в insert одной строки и последующем select (id). Еще поосвобождать сегменты отката, еще куча других вещей. Если бы commit был таким простым, то в MYSQL давно бы ввели транзакции.

>Не путайте подключение через ODBC драйвера и подключение через native интерфейс PB - это разные вещи.

Возможно, никогда не работал с native интерфейсом. Может лучше использовать ODBC? По-видимому использование ODBC не такой уж плохой подход, раз родной для PB сервер ASA работает через ODBC, native драйвера нет вообще.

2 ASCRUS
>>И чем же commit гораздо длиннее insert/select - поставить флажок в журнале, что транзакция подтверждена - это долго?
>Очень спорный вопрос и для каждой СУБД ответ может быть свой. Лично я думаю, что для блокировочников COMMIT будет быстрее Insert

Там речь шла даже не о скорости insert, а о времени между завершением insert и отработкой select max(id), т.е. фактически о скорости select.

2 Локшин Марк

>См. help по AtAtIdentity DBParm parameter

В каком PB смотреть? Вы же сами сказали, что это не PB6 (Локшин Марк>Можно, но не в pb.ini и не в PB6.). Не загадывайте загадки.

>Хорошо. Ответ нельзя вас устроит?

Так можно или нельзя? Или нельзя только в PB6, а в более поздних версиях можно? Дайте же хоть немоного информации, может кому-нибудь пригодится.

>Снять флажок. Проблем то.

Если только флажок, то проблем нет. Но что-то подсказывает мне, что commit одним флажком не ограничивается. Например потому, что в транзакции могут быть задействованы несколько таблиц. В нашем примере таблица одна, но система заранее этого не знает. А еще у каждого пользователя свои транзакции. Это уже много флажков. А еще транзакции могут быть вложенные, плюс всякие там savepoint и пр. Есть еще много других причин, по которым одним флажком дело обойтись не может. Хотя среди прочих дествий система возможно и флажок снимает.

>Непосредственно для проведения COMMIT'а серверу надо убедиться, что записи log файла относящиеся к данной транзакции скинуты на диск и снять блокировки. ...

Т.е. одним флажком все-таки дело не обходится.

>Транзакция - это не только COMMIT.

Правильно, это еще и rollback. Так по Вашей логике для отката нужно только удалить запись, помеченную флажком как новая, снять флажок у удаленных записей и восстановить обновленные записи. Тоже ничего сложного, по крайней мере на 7 (или сколько там) лет работ, которые MYSQL потратил чтоб реализовать транзакции, никак не тянет.

Я предлагаю не прдолжать этот спор о сложности или простоте транзакций, я же и сам сразу признал, что на такие вещи полагаться не стоит. Либо давайте говорить предметно, со ссылками на документацию.

Возражения против использования ODBC вместо native драйвера есть?

2 Локшин Марк

>Так вот, речь там идет и о времени INSERT (подумайте почему).

Подумал. Все равно не понимаю. Вторая транзакция может испортить id только после завершения инсерта первой транзакции, не важно сколько инсерт длится, хоть час. Потом отрабатывает селект первой транзакции. Тут уже важно, сколько он отрабатывает, поскольку первая транзакция получит id только после завершения селекта и если вторая транзакция испортит id, то будет ошибка. Более того, поскольку SQL операции атомарны по определению (в нормальных SQL серверах), тем более однострочные инсерты и селекты, то нас интересует даже не продолжительность операций insert-select, а длина промежутка между ними. Не верю, что в этот промежуток успеет отработать коммит. Повторяю, что полагаться на это конечно нельзя.

>Ссылку я уже привел, даже для версионника, где с этим сложнее. Там, кстати, есть и определение транзакции.

Не знаю где транзакции проще, ссылочку бы на этот счет. Определение транзакции все-таки лучше смотреть в первоисточниках. Ссылки почитаю на досуге.

>native драйвера - предмет особой гордости PowerSoft'а/Sybase'а. :)

Их гордость это их проблема. Наша проблема - нужно работать, причем желательно поменьше. Если ODBC позволяет решать поставленную задачу, а другие методы имеют проблемы, то нужно пользоваться ODBC. Так есть аргументы против него?

2 Локшин Марк

> Так вот, поясняю на пальцах, если не понятно.
1. 1-я транзакция делает INSERT. Значение автоинкремента для таблицы будет увеличено _до_ окончания момента вставки первой транзакции. Кроме увеличения автоинкремента ей необходимо сделать еще кучу вещей - считать страницу данных, страницы индексов, вставить туда записи, возможно заняться так называемым расщиплением страниц, записать то, что она делает в лог транзакций. И кроме того, на протяжении всех этих действий исполенения потока, который этим занимается, может быть приостановлено ОС в любой момент времени.
2. 2-я транзакция делает INSERT, получая значение автоинкремента большее, чем у 1 транзакции. А вот второй транзакции не потребовалось расщиплять страницы, затребованые данные были в кэше и ОС не приостанавливала выполнение связанного с ней потока.
3. 2-я транзакция делает SELECT
4. 2-я транзакция делает COMMIT (данные стали видны для первой транзакции)
5. 1-я транзакция делает SELECT max(identitycol) и получает значение автоинкремента для 2-й транзакции.
Теперь понятно? Больше объяснять не буду.

Понятно только, что все построено чистых предположениях: приостановка потоков, взаимодействие с OS. С точки зрения OS потоков в SQL сервере может вообще не быть. Еще раз повторяю, без ссылок на конкретные механизымы конкретных SQL серверов обсуждать такие детали смысла не имеет. И еще раз предлагаю завязывать с этой частью обсуждения.

>Если достаточно большой проект изначально писался с использованием native драйверов, то при переводе его на работу через ODBC, по хорошему, его надо полностью заново тестировать.

Согласен, но проект вообще нужно иногда тестировать. Странно только, что проблема с ID обнаруживается только когда этот большой проект уже почти написан.

Еще возражения против ODBC?

2 Локшин Марк

>Одного этого уже достаточно, чтобы INSERT первой транзакции закончился после COMMIT'а второй.

Одного этого не достаточно. В лучшем случае это необходимо. Вы же сами упоминали какие-то страницы, предполагали что ID увеличивается в начале инсерта и пр.

>У PB эта проблема возникает только при достаточно большой нагрузке на систему. Кто же знал, что программисты из Sybase'а такую подлянку подложат? Тестированием такую проблему выявить достаточно сложно.

Вы тут теоретически обосновали эту проблему и даже привели ссылки на микрософт, при этом ни в ссылках и ни в теоретических рассуждениях не упоминался PB, а только SQL сервер. Т.е. проблема от клиента не зависит. Большая нагрузка тоже не играла в ваших рассуждениях ключевой роли. Получается проблема была легко предсказуема как только вы обнаружили остутствие возможности работы с @@identity в драйвере, а это наверное случилось в начале работы над проектом. Просто вы не подумали. Так при чем тут PB и программисты Sybase, которые к тому же рекомендуют использовать ODBC?

По-моему Вы преувеличиваете проблемы с переходом на ODBC. По крайней мере в сравнении с теми усилиями, которые вы по-видимому затратили на борьбу с @@identity.

2 Локшин Марк

>Во-первых этого достаточно.
>Большая нагрузка повышает вероятность возникновения ошибки.

Ликбез по необходимым и достаточным условиям. В связке Y=>X (из Y следует X) высказывание Y называется достаточным для X, а X называется необходимым для Y. Вот Вы говорите: "separate operating system thread is created for each client connection to consume fewer system resources....". Это высказывание Y.
Дальше:"Одного этого уже достаточно, чтобы INSERT первой транзакции закончился после COMMIT'а второй." Высказывание X это "INSERT первой транзакции закончился после COMMIT'а второй". Это последнее ведет к возникновению ошибки с ID необходимостью, т.е. можно сказать что высказывание X это: "select max(id) возвращает неверное значение" (поскольку из Y=>X=>Z следует Y=>Z). Потом Вы заявляете, что "Большая нагрузка повышает вероятность возникновения ошибки." Тут два варианта: либо вероятность не повышается, поскольку и так равна 1, либо Вы в каком-то месте напутали с необходимымы и достаточными условиями.

Аналогично вместо высказывания "Большая нагрузка повышает ..." можно подставить Ваши рассуждения о каких-то страницах в MSSQL сервере и моменте заведения ID. Если условия Y в самом деле достаточно, то абсолютно НЕ ВАЖНО что происходит со страницами памяти и в какой момент увеличивается ID, поскольку X (ошибка) все равно возникнет. А если страницы важны и без них не обойтись, то следовательно условие Y не является достаточным. Выбирите что Вам дороже, а от другого откажитесь.

>Исключительно проблема клиента.

Какого клиента, если в Ваших замечательных теоретических обоснованиях клиент не фигурировал вообще. А если PB заменить на дельфи или фокспро и брать ID по select max(id) ... в Ваших рассуждениях про какие-то страницы и какие-то потоки что-нибудь изменится?

>На тот момент native интерфейс PB позиционировался как неоспоримое его преимущество.

Я три раза повторил вопрос: в чем преимущество? Нет ответа. Они позиционируют - это их проблемы. А работа не выполнена - это Ваши проблемы. Что Вам дороже?

>"Причем тут программисты Sybase" - написали драйвер и говорят - не используйте его, используйте другой, который мы не писали. :)

Эта ситуация встречается на каждом шагу. FAT поддерживается в NT, но к использованию не рекомендуется, особенно на серверах.

>Реализовали некорректный способ получения автоинкрементного значения, через много лет признали это и исправили, и они здесь не при чем?

Ну во-первых Вы же сами признали, что при некоторых уровнях изоляции метод корректный. То что он некорректный в других случаях знатокам MSSQL должно было быть ясно с самого начала (это по результатам дискуссии).
Во-вторых метод рекомендованный, можете применять другой если получится. Кстати не знаю где Вы его откопали, я его надыбал в файле PBODBх0.INI, который к native interface вроде бы отношения не имеет, а имеет отношение как раз к ODBC. Там он идет как исключение, когда ничего лучшего не нашлось.
В-третьх, насколько я понял из Ваших слов, в следующих версиях проблему исправили.
В-четвертых в PB нет проблем в переходе от родного драйвера к ODBC, OLEDB, JDBC и пр., если PB приложение написано в соответствии с рекомендациями сайбейза разумеется.

Не понимаю, какие претензии к производителю. Пишите правильно программы, думайте до начала программирования, а не после окончания, и проблем будет гораздо меньше.