Axapta 3.0 Kernel Rollup 1 Service Pack Release - Microsoft и системы Microsoft Dynamics

**mazzy** · 19.01.2006, 20:35

Axapta 3.0 Kernel Rollup 1 Service Pack Release

Microsoft Axapta 3.0 Kernel Rollup 1 can be installed on customer sites running Microsoft Axapta 3.0 SP2, SP3 and SP4. The kernel rollup provides compatibility with Microsoft SQL Server 2005, Optimistic Concurrency Checking for Microsoft SQL Server 2000 & Microsoft SQL Server 2005, Enhanced SQL Tracing Utilities, Increased SQL Query Performance, AOS Enhanced Stability & Logging, AOS Abort if Listener Thread Fails, and a link to an application update for Enhanced Password Security, as well as other improvements.

Supported platforms include:

· Microsoft Windows 2000 Server SP4 Update Rollup1
· Microsoft Windows 2003 Server SP1
· Microsoft Windows XP SP2
· MDAC 2.8 SP1 (Client & Server)
· Microsoft SQL Server 2000 SP4, 32-bit & 64-bit
· Microsoft SQL Server 2000 Analysis Services with SP4
· Microsoft SQL Server 2005, 32-bit & 64-bit
· Oracle 9i patched to version 9.2.0.

(доступ для партнеров)
https://mbs.microsoft.com/Cms/Templates/doc...printpage=false

**mazzy** · 19.01.2006, 21:14

Будьте предельно внимательны.

Изменилась версия ktd-файла. Изменения незначительны. Но прежде, чем ставить обновление на рабочую базу - протестируйте.

Если для вас надежность критична, подождите выхода российской версии.

**mazzy** · 19.01.2006, 21:27

См. также Версии и билды

raz · 20.01.2006, 15:46

На последнем клубе клиентов представители MS говорили, что этот сервиспак будет общедоступным, но, как обычно, выложили на партнерском сайте. У MS есть много общедоступных обновлений к Аксапте, про которые клиенты даже не знают, но все они доступны только партнерам - странная политика.

**mazzy** · 21.01.2006, 20:19

Цитата:

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

На последнем клубе клиентов представители MS говорили, что этот сервиспак будет общедоступным...

Я не знаю про обещания Майкрософт - это вы у них спрашивайте.

Я знаю про договор - право на обновления имеют те клиенты, которые имеют активную подписку на обновления. Я, например, ничего не знаю об изменении политики в отношении обновлений.
Однако, практика бывает разная http://www.mibuso.ru/forum/index.php?showtopic=10519

Спросите у того, кто обещал. Лично. Получите ответ.
Опубликуйте здесь.

**mazzy** · 24.01.2006, 22:36

Совет Алексея Еременко

Как временное решение по локализации ktd файла можно предложить следующие изменения axsysru.ktd из 3.0SP4:
1. тэг #269
Между строками содержащими "Space()" и "1245" добавляется строка Apostrophe (')
2. тэг #1144
В конце тэга после строки с "MenuItemId" добавляется строка RecVersion
4. тэг #268
В конце тэга после строки с "Запись не может быть удалена. В таблице "%s" существуют проводки" добавляется строка
Запись может не соответствовать настройкам защиты на уровне записей по таблице "%s".
3.Номер версии файла в самом начале изменить с 587 на 588

**Maxim Gorbunov** · 25.01.2006, 16:46

А кто-нибудь пробовал уже его для работы с MS SQL 2005? Несколько раз перечитал readme, там как-то путано написано.

В моем вольном переводе:
1. После установки KR1 Axapta может быть запущена в compatibility- или native-режиме.
2. В compatibility-режиме MS SQL 2005 будет вести себя так же, как и MS SQL 2000.
3. В native-режиме Axapta не использует преимущества новой архитектуры MS SQL 2005.

В связи с этим, вопрос: а какой смысл тогда в использовании KR1 и MS SQL 2005 с Axapta?

И про Optimistic Concurrency Checking кто-нибудь может доходчиво объяснить, что имелось ввиду? Опять же, в моем переводе:
1. Раньше перед выполнением update, Axapta перечитывала запись с сервера, сравнивала ее с той, что хранилась в памяти и, если они были одинаковыми, строила новую запись и записывала ее в БД.
2. Теперь Axapta также перечитывает запись c сервера и, если она не изменилась, выполняет update.
3. Короче говоря, если нет конфликта, то выполняется только один запрос к БД.

Вызывает интерес значение именно пункта 3: почему один-то, когда запись все равно перечитывается?

**Vadik** · 25.01.2006, 18:08

Цитата:

Сообщение от Maxim Gorbunov

А кто-нибудь пробовал уже его для работы с MS SQL 2005?

только локально, но руки чешутся накатить его на внутреннюю систему

Цитата:

Несколько раз перечитал readme, там как-то путано написано.
В моем вольном переводе:
1. После установки KR1 Axapta может быть запущена в compatibility- или native-режиме.
2. В compatibility-режиме MS SQL 2005 будет вести себя так же, как и MS SQL 2000.
3. В native-режиме Axapta не использует преимущества новой архитектуры MS SQL 2005.

1. я бы сказал, что в режиме совместимости 80 оно с юконом и до KR1 работало
2. версионность, например, в режиме совместимости уже работает, так что скорее всего не совсем "так же"
3. полагаю, имеется в виду то, что не используется native client

Цитата:

В связи с этим, вопрос: а какой смысл тогда в использовании KR1 и MS SQL 2005 с Axapta?

навскидку:
- в режиме совместимости 90 можно смотреть красивые отчеты по базе в Management Studio

- можно пользоваться секционированием (для приложения это ведь прозрачно)
- новый механизм отслеживания deadlock-ов (с которым еще разбираться надо)

Цитата:

И про Optimistic Concurrency Checking кто-нибудь может доходчиво объяснить, что имелось ввиду?

думаю, без поллитры и профайлера не разобраться

ну ничего, скоро выходные, а там посмотрим

**mazzy** · 25.01.2006, 19:25

Цитата:

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

Цитата:

Сообщение от Maxim Gorbunov

А кто-нибудь пробовал уже его для работы с MS SQL 2005?

только локально, но руки чешутся накатить его на внутреннюю систему

Я - за!

**George Nordic** · 26.01.2006, 10:54

Цитата:

Сообщение от Maxim Gorbunov

И про Optimistic Concurrency Checking кто-нибудь может доходчиво объяснить, что имелось ввиду?

Грязное чтение.
Настраивается или для всей системы сразу, или для каждой таблицы отдельно. (как свойство)

К тому же, в 4ке у select появятся хинты "optimisticlock" и "pessimisticlock", разрешающие/запрещающие грязное чтение.

С Уважением,
Георгий

**Vadik** · 04.02.2006, 14:14

Отобрали, блин, у ребенка любимую игрушку - перестали работать настройки Hint flags в конфигурационной утилите

**Maxim Gorbunov** · 07.02.2006, 11:29

Цитата:

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

- в режиме совместимости 90 можно смотреть красивые отчеты по базе в Management Studio

- можно пользоваться секционированием (для приложения это ведь прозрачно)
- новый механизм отслеживания deadlock-ов (с которым еще разбираться надо)

А 2 и 3 не следуют из 1? То есть разница в том, что клиент SP4 работает только в режиме совместимости 80, а KR1 - в режиме 90, правильно?

Цитата:

Сообщение от George Nordic

Грязное чтение.
Настраивается или для всей системы сразу, или для каждой таблицы отдельно. (как свойство)

Понимаешь, логически мысля, я тоже предположил, что это грязное чтение. Только вот то, что написано в Readme, на алгоритм для грязного чтения не похоже как то. Или я не понимаю, что там написано.

**Vadik** · 07.02.2006, 23:43

Цитата:

Сообщение от Maxim Gorbunov

И про Optimistic Concurrency Checking кто-нибудь может доходчиво объяснить, что имелось ввиду? Опять же, в моем переводе:
1. Раньше перед выполнением update, Axapta перечитывала запись с сервера, сравнивала ее с той, что хранилась в памяти и, если они были одинаковыми, строила новую запись и записывала ее в БД.
2. Теперь Axapta также перечитывает запись c сервера и, если она не изменилась, выполняет update.
3. Короче говоря, если нет конфликта, то выполняется только один запрос к БД.

Вызывает интерес значение именно пункта 3: почему один-то, когда запись все равно перечитывается?

Дело в следующем (с). Как уже писалось на axforum-е, сейчас в структуре данных добавлено новое поле - RECVERSION, инициализируется оно значением 1, далее при каждой модификации оно меняется (как генерируется - непонятно, да и не важно, допустим, случайным образом, главное, что две сессии сгенерят два разных значения). При изменении (UPDATE) записи

РАНЬШЕ:
- запись перечитывалась по RecId (select * from myTable where DataAreaId = .. and RecId = ..
- изменения, которые могли быть сделаны другими сессиями, merge-ились с изменениями в текущей сессии

СЕЙЧАС:
- запись не перечитывается, сразу выполняется update myTable where DataAreaId = .. and RecId = .. and RECVERSION = ..
если кто-то уже изменил эту запись, поле RECVERSION имеет уже другое значение и фактически мы "пролетаем" с оператором UPDATE - количество обработанных записей (@@ROWCOUNT) = 0. Поэтому система перечитает запись по RecId и продолжит работу как ни в чем ни бывало (по старому алгоритму)

Т.е. количество операций в среднем по системе таки должно уменьшаться и выигрыш вроде бы есть. Единственное НО: этот механизм работает только на формах (данные, которые отбираются для изменения из кода, уже заблокированы с select forupdate), а данные на формах (по моим ощущениям) вроде бы не особо интенсивно меняются. Стоило ли для это добавлять новое поле во все таблицы - ну, вендору виднее

**Vadik** · 08.02.2006, 00:00

Цитата:

Сообщение от Maxim Gorbunov

Понимаешь, логически мысля, я тоже предположил, что это грязное чтение. Только вот то, что написано в Readme, на алгоритм для грязного чтения не похоже как то. Или я не понимаю, что там написано.

Цитата:

Well, maybe if you wrote it in f*** English, I would f*** understand it

Это не грязное чтение. Это обновление по оптимистическому алгоритму - мы ПРЕДПОЛАГАЕМ, что запись не успели обновить до нас. Если это не так (кто-то влез с UPDATE перед нами), нам придется проделать дополнительную работу при повторной попытке выполнить обновление, в этом случае операция в целом будет дороже с точки зрения IO, чем при пессимистическом алгоритме. Если конфликты при обновлении случаются относительно редко, выигрыш с точки зрения ввода-вывода есть

Torin · 11.05.2006, 15:03

Давайте отделим божий дар и яичницу.
Под словом "версионник" понимают, что ядро СУБД:
1) хранит копию прочитанной записи, копию записанной записи, пока есть открытые курсоры.
2) при записи сравнивает версию прочитанной и записываемой записи.
3) В целом поднимает производительность, позволяя читать и писать одновременно (разным соединениям), до деедлока или "отбрасывания изменения". Мерджи технически невозможны !

http://rsdn.ru/article/db/yukonvers.xml
http://msdn2.microsoft.com/en-US/library/m...90(SQL.90).aspx
надо сказать, что еще стоит изучить - как и что использует Аксапта из этого, или руками "допилить"

Оптимистическая блокировка отличается от пессиместической тем, что первая разрешает изменение прочитанной записи другим соединениям, а вторая - нет. Т.е. если клиент СУБД не должен нарваться на чухое изменение, то он пессиместичен. Но такие штуки являються узким местом конкурентного доступа. Трансакции должны бтыь как можно короче.

Механиз кеширования аксапты на уровне AOS (если я правильно понял) сами по себе должны быть связанны теми же "правилами конкурентного доступа", что и СУБД. Посему стоит отличать механизм реализации конкурентности кэша АОС и самой СУБД (про толстого клиента не знаю, пока не существенно). Говорят, что есть кеш 1-го уровня и 2-го. У каждого свой протокол.

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

2) Тогда логично про замечание, будто запросы из коды сразу с Update блокировкой - в данном случае вообще не используеться кеш Аксапты, а напрямую поддержка версионностив СУБД.

3) Вероятно, должно быть время "обновления" кеша АОС-а, не всегда же показывать "тутфту" пользователю.

Надо сказать, выглядит вполне продумано (в Аксапта). Даже не к чему придраться. Главно, чтобы работало так как надо.

itfs_imported · 11.05.2006, 17:22

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

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

**Vadik** · 11.05.2006, 23:45

Цитата:

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

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

Если "некоторые" - это я

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

Torin · 12.05.2006, 12:03

Цитата:

Сообщение от 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 я называю то, что происходит, если к примеру из одной сессии поменять название номенклатуры, а из второй - номенклатурную группу.

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

velk · 17.07.2007, 12:23

Здравствуйте
а подскажите пожалуйста с каким обновлением появляется поле RecVersion
после какого сервис пака
устнавливали sp4 нет изменений потом установили sp5 ругется что нету поля RecVersion :-(

**Vadik** · 17.07.2007, 16:21

Цитата:

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

Здравствуйте
а подскажите пожалуйста с каким обновлением появляется поле RecVersion
после какого сервис пака
устнавливали sp4 нет изменений потом установили sp5 ругется что нету поля RecVersion :-(

SP5 ставит KR1