Используемые версии ядра

[Logger]

Здравствуйте.
Задумал я поменять текущую версию ядра аксапты ( не меняя приложение). Есть желание собрать статистику кто какими билдами пользуется.

P.S.
Полезная ссылка
http://blogs.msdn.com/b/axsupport/ar...d-numbers.aspx

Все возможные версии в опрос не влезли (возможен только 21 вариант ответа). Отписывайте в теме свои варианты, для которых нет подходящего варианта в опросе.
Опрос закрытый.

[DSPIC]

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

[Logger]

Конечно имеет.
Позволяет устранить баги ядра. Иногда привносит новую функциональность, как тут
AX 2009 Technical Journal: AX 2009 SP1, Parameter Sniffing finally addressed by Microsoft

правда, могут и новые баги добавиться. Но это при любом обновлении может быть.

[Link]

Цитата:

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

Конечно имеет.
Позволяет устранить баги ядра. Иногда привносит новую функциональность, как тут
AX 2009 Technical Journal: AX 2009 SP1, Parameter Sniffing finally addressed by Microsoft

правда, могут и новые баги добавиться. Но это при любом обновлении может быть.

Не совсем так, нужно уточнить, что иметь последнюю версию ядра это хорошо и рекомендуется МС, но она обязательно должна соответстовать версии у уровню сервис пака, так как совместимость поддерживается только в таком соотношении.

Цитата:

Q8: Is it supported to have a different kernel and application build?

YES, it is supported to have different builds for the application and the kernel BUT... they must be for the same version and service pack level.

Our Product Group ensure that dependencies between the application and kernel are not introduced when creating AX hotfixes. Dependencies between the application and kernel builds can only be introduced in a new product version and a new service pack (NOT in a rollup/cumulative update).

We also recommend having a kernel build that is the same or higher build than the application build. Applying a kernel update is normally a simpler process than updating the application code, so in the case of applying a cumulative update it makes sense to apply the kernel part of the update as well as the application part. This also ensures that you get the full benefit from any hybrid fixes, which as mentioned above require updates in both the kernel and application to function fully.

[Logger]

up

[Товарищ ♂uatr]

Затрудняюсь с пониманием какое CU "6.2.1000.9871", но именно такая стоит версия серверного приложения.

[Logger]

up

[Ivanhoe]

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

[Logger]

2009 RU7
Но я как раз от него хочу уйти. Нестабильно работает пакетный аос.
Подумываю про
2009 SP1 RU8.xxx + Latest kernel build (5.0.1600.3090)
или про
2009 SP1 RU8.xxx + Recent published kernel build + parameter sniffing fix (5.0.1600.2967)

P.S.
Несколько напрягают существующие в них баги
http://thebesthacker.com/question/ht...h-columns.html
Хотя на нас они наверно и не скажутся.

[Logger]

Кстати, удивительно, как много людей еще использует трешку. Не ожидал таких показателей.

[Logger]

Цитата:

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

Мне кажется, общая статистика в таком вопросе мало показательна.

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

[Ivanhoe]

Сидят, куда деться, если проект стоил кучку миллионов, в ходе проекта не ставились обновления, а ценник на переход Заказчика повергает в ужас?

Знаю клиентов на нулевых билдах R2 / R3 в 2012, в 2009 много RU5, особенно среди западных дочек.

[Ivanhoe]

Цитата:

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

2009 RU7
Но я как раз от него хочу уйти. Нестабильно работает пакетный аос.
Подумываю про
2009 SP1 RU8.xxx + Latest kernel build (5.0.1600.3090)
или про
2009 SP1 RU8.xxx + Recent published kernel build + parameter sniffing fix (5.0.1600.2967)

Я бы ставил это на ядро: 5.0.1600.3090, само приложение менять - только если реально понимаете выгоды.

[Logger]

Спасибо за инфу.
Я пока не думал менять приложение, только ядро.

[Logger]

Цитата:

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

Сидят, куда деться, если проект стоил кучку миллионов, в ходе проекта не ставились обновления, а ценник на переход Заказчика повергает в ужас?

Ну приложение перевести геморно конечно (особенно если много модификаций).
А в чем проблема ядро обновить ? Просто очкуют ?

[Ivanhoe]

Например на 2012 есть особенности - ядро к функциональности привязано, т.е. до Cu7 / после будут проблемы.

Обычно "если работает, то не трогай" все-таки преобладает Те, у кого пакетники падают или еще что подобное происходит, конечно, начинают искать варианты и обновить ядро до последнего - логичный выход. Если обращаться по системным проблемам в MS, там тоже первая рекомендация - обновить ядро.

[gl00mie]

Цитата:

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

Сидят, куда деться, если проект стоил кучку миллионов, в ходе проекта не ставились обновления, а ценник на переход Заказчика повергает в ужас? Знаю клиентов на нулевых билдах R2 / R3 в 2012, в 2009 много RU5, особенно среди западных дочек.

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

[Logger]

Цитата:

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

Например на 2012 есть особенности - ядро к функциональности привязано, т.е. до Cu7 / после будут проблемы.

Ого !
Про это не знал. А вы ничего не путаете ?
Как выше в теме написали ядро можно менять только внутри сервис пака.
Т.е. если стоит AX 2012 R2 CU7 то не надо ставить ядра от AX 2012 R3 CU7-CU8 и.т.п.

Вы не это имели в виду ?

[gl00mie]

Цитата:

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

Как выше в теме написали ядро можно менять только внутри сервис пака. Т.е. если стоит AX 2012 R2 CU7 то не надо ставить ядра от AX 2012 R3 CU7-CU8 и.т.п. Вы не это имели в виду ?

С официальной точки зрения R2 и R3 - это не service pack к AX 2012, это отдельные релизы продукта, грубо говоря, разные версии, имеющие много общего (в т.ч. подстроку "AX 2012" в названии), но и очень многим отличающиеся. К счастью, установщик обновлений просто не даст поставить ядро от R3 на инсталляцию R2

Цитата:

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

Обычно "если работает, то не трогай" все-таки преобладает Те, у кого пакетники падают или еще что подобное происходит, конечно, начинают искать варианты и обновить ядро до последнего - логичный выход.

Если периодически читать, что именно исправляют в обновлениях ядра, то просто страшно становится. Это как у медиков: пациенты делятся на больных и необследованных.

[Ivanhoe]

Цитата:

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

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

Если менять только ядро и не приходится менять приложение - то это дешево, согласен что моя фраза получилась не совсем корректной. Если затрагивается функциональность (например, DMF) - то тут сложнее уже.

Если клиенты стоят по рабочим станциям, а нормального администрирования в компании нет - это тоже может занять много времени и ресурсов.

Но в целом моя фраза применима к тем компаниям, в которых ИТ - это некая магия и нет нормального внутреннего ИТшника (а он, например, и в ходе проекта будет настаивать на обновлениях ядра / приложения, покрайней мере до первого билда).