Axapta 3.0 Kernel Rollup 1 Service Pack Release

[itfs_imported]

2 Torin
Спасибо за ссылки, получил удовольствие.
Но вы ведь не думаете всерьез, что кеш Аксапты реализует хоть какие-то функции СУБД, не говоря уже о совмесном доступе (версионном или блокировочном)?
Как я понимаю, просто новое поле позволяет принимать более гибкие решения при выполнении операций чтения и записи, реализующих ту самую стратегию (Optimistic Concurrency Checking).
Не более, того. А то что введение этого новшества совпало с выходом SQL 2005, это что-то вроде ненавязчивого совпадения, имеющего маркетинговый подтекст.

С уважением, itfs.

[Torin]

Цитата:

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

2 Torin
Но вы ведь не думаете всерьез, что кеш Аксапты реализует хоть какие-то функции СУБД, не говоря уже о совмесном доступе (версионном или блокировочном)?
Как я понимаю, просто новое поле позволяет принимать более гибкие решения при выполнении операций чтения и записи, реализующих ту самую стратегию (Optimistic Concurrency Checking).
Не более, того. А то что введение этого новшества совпало с выходом SQL 2005, это что-то вроде ненавязчивого совпадения, имеющего маркетинговый подтекст.
С уважением, itfs.

Кеш второго уровня, каким яляется кеш Аксапты, может принимать любые формы. Но его назначение в случае с Юконом, IMHO, состоит в снижении нагрузки на базу для данных, которые выводяться в формы (списки), не более. Учитывая, количество открытых форм и пользователей, это также существенно сокращает открытые соединения к базе, и экономит ресурсы СУБД.
Уверен (хотя еще проверять - просто я и сам так делал в решениях и много изучал эту тему), что:
1) Кеш Акспаты всегда отключен от базы данных, но переодически обновляется
2) При редактировании записи в интерфейсе (так как нет кнопки "открыть на изменения" - он проверяет версию записи сам, по полю RECVERSION. Других способов нет, в его случает.
Свойства же "версинника" Юкона проявляется на других операциях - паралельные транзакции из кода
, или возможность строить отчеты, например, и при этом что-то менять в базе. "Блокировочник" Шилон - просто зависал на них. Все эти операции имеют одно отличие от списков в интерфейсе - от начала и до конца операции они работают через постоянное соединение с базой.

Цитата:

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

Цитата:

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

Таким образом, думаю, что:
1) RECVERSION относиться только к реализации "конкурентности" кеша AOS, который может держать образ записей без соединения с базой. Конструкция "update myTable where DataAreaId = .. and RecId = .. and RECVERSION = " может быть использована только в этом случае (из интерфейса). ТОлько в таком случае для версионника (когда выбрали, отключились от базы, опять подключились и делаем изменение) может быть касус с потерей данных (мердже, как некоторые называют)

Если "некоторые" - это я , то merge я называю то, что происходит, если к примеру из одной сессии поменять название номенклатуры, а из второй - номенклатурную группу.

Я не акцентировался на этом, - это термин "потерянное обновление" по классике.
При постоянном подключении к базе, так в Юконе сделать нельзя ;-)