RecordSortedList forUpdate

[db]

Цитата:

Сообщение от Logger

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

Он сам перевыберет из базы обновит значения и запишет.

Одно неудобство - метод предполагает что есть индекс по RecId - иначе очень долго выборка пойдет. Ну это можно довинтить...

Ну вы блин даете

Курсор это не какая то волшебная конструкция, которая обновляет запись непонятным образом минуя SQL. Когда вы пишете update(), то просто генерится команда update .. set .. where критерии по уникальному индексу. У каждой таблицы аксапты есть уникальный индекс, даже если он явно не указан (аксапта создаст его сама, приделав RecId к какому нибудь индексу или просто создаст индекс по RecId)

Соответсвенно вышеописанный способ с глобальным методом попытка закодить то что уже в ядре и так есть

Про forupdate. Сервер БД не запрещает выбирать записи без forupdate, а потом изменять их. Это лишь определяет момент наложения блокировки - сразу при выборке или потом при обновлении. Кому интересно - читайте доки по вашей СУБД

Авторы аксапты решили (начиная с 3.0) что хорошим тоном будет являться накладывать блокировку сразу при выборке. Поэтому и появилась проверка на транзакцию и на forupdate. Но возможность выключить проверку осталась - skipTTSCheck(true)

[Logger]

Цитата:

Сообщение от db

Когда вы пишете update(), то просто генерится команда update .. set .. where критерии по уникальному индексу. У каждой таблицы аксапты есть уникальный индекс, даже если он явно не указан (аксапта создаст его сама, приделав RecId к какому нибудь индексу или просто создаст индекс по RecId)

Соответсвенно вышеописанный способ с глобальным методом попытка закодить то что уже в ядре и так есть

Мне кажется вы невнимательно прочитали мое сообщение.
Проблема может возникнуть при выборке по условию
locCommon.RecId == _common.RecId;

[db]

Цитата:

Сообщение от Logger

Мне кажется вы невнимательно прочитали мое сообщение.
Проблема может возникнуть при выборке по условию
locCommon.RecId == _common.RecId;

Может я действительно чего не втыкаю, тогда пжл проясните

У Вас в методе, если запись по RecId не нашлась, то ничего и не делается. В стандарте сформируется SQL команда Update с критериями по уникальному индексу. Если в базе к тому моменту записи с такими критериями не будет, то update просто "пролетит" мимо - результат то же самый - ничего не изменится

[Logger]

Цитата:

Сообщение от db

Может я действительно чего не втыкаю, тогда пжл проясните

У Вас в методе, если запись по RecId не нашлась, то ничего и не делается. В стандарте сформируется SQL команда Update с критериями по уникальному индексу. Если в базе к тому моменту записи с такими критериями не будет, то update просто "пролетит" мимо - результат то же самый - ничего не изменится

Я имел в виду что если нет индекса по RecId, то запрос с фильтром по RecId будет медленно работать. В каком виде уходит запрос на сервер привыполнении Update() - я не обсуждал.

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

db, а почему вы так агрессивно реагируете на сообщения ? На вас тут никто не наезжал. Погода хорошая... В чем дело-то ?

[db]

Цитата:

Сообщение от Logger

db, а почему вы так агрессивно реагируете на сообщения ? На вас тут никто не наезжал. Погода хорошая... В чем дело-то ?

Извините, никого не хотел обижать

А, насчет агрессивно. Хм. Если бы видели мою агрессивную реакцию, то поняли бы что в данной ситуации я просто молчу ... Характер у меня такой, стервозный Спросите, например, у Recoilme. Он видел