belugin
Мне почему-то вспоминается комплекс из телевизора, уха и отвертки.

мне тоже

belugin
Давайте подойдем к вопросу со стороны того, кто покупает аксапту сейчас - топик об этом:
- какой шанс у него получить ax3?

Не, Максим, здесь я категорически не согласен.
Даже если ax3 устарела и снята с поддержки, все равно и для этой системы надо предлагать решения. Ведь люди есть.

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

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

В основном у моих клиентов подобных проблем не возникало, при этом оборудование было значительно попроще, чем у Волочковой.

Но как и другим в этой ветке, мне похоже не поверят.

Что ж, первый шаг в РЕШЕНИЮ проблем описан здесь http://axapta.mazzy.ru/lib/querytuning/

SeVaавторЧто ж, первый шаг в РЕШЕНИЮ проблем описан здесь http://axapta.mazzy.ru/lib/querytuning/
Да, практически все хинты в Аксапте левые,интересно,кому это нужно,чтобы их потом выковыривали?
Их делали в другое время и в другие времена.
Когда и базы были меньше, и еще cost optimizer не был таким сильным.
Еще когда все надежды были на syntax оптимизацию.

С тех пор много времени прошло.
Еще в ax4.0 полностью убрали все хинты из кода. А для ax3 добавили параметр запуска hint flags (см. документацию и axforum).

SeVa
Еще вопрос.Уважаемые ахаптовцы,не ститаете ли вы,что наличие грязного чтения, превращает результаты запросов в помойку?Зачем тогда блокировки?
В формах - нет, не превращает.
В отчетах... Тут всякое бывает. Но чтобы избавиться от "помойки" достаточно тело отчета заключить в транзакцию.
А все обновления делаются только в транзакции (там грязного чтения нет)
Поэтому я не думаю, что грязное чтение является проблемой.

SeVa
А,что слышно о проете Green(если не изменяет память,собирались перевести весь свой зоопарк на единый фреймворк)?
Работа идет. Потихоньку все переводят на .net (неторопливо и с обязательным сохранением совместимости)
Первая волна Project Green завершена
Историю project green см. http://forum.mazzy.ru/index.php?showtopic=447&st=40&start=40
правда сейчас этот проект так не называют.

последние новости http://forum.mazzy.ru/index.php?showtopic=13175
Также Поищите Green на axforum.info и forum.mazzy.ru

IgorKДля торарищей mazzy и belugin - я пришел в Аксапту из "другого мира" разработки для СУБД, где утверждалось и доказывалось что работать с MSSQL на уровне курсоров - есть моветон и прямой путь к тормозам и проблемам, что прекрасно демонстрирует Аксапта. Идеология работы ядра не поменялась на в 4 ни в 2009 версии - и не зависит от версии СУБД.
И пока менять его не собираются.
IgorK - никто не говорит, что курсоры - идеальное решение. Но в то же время и не самое худшее решение.
Я, например, утверждаю, что у Волочковой запущенный случай, и попытка свалить всю беду на курсоры... Хм...

Выбранное решение - результат компромиссов в течение 20 лет развития.
о развитии см. http://axapta.mazzy.ru/lib/names/

Выбранное решение оправдывает себя в системе, которая должна работать с несколькими СУБД (здесь на SQL.ru была ветка о поддержке нескольких СУБД и о технологических компромиссах).

В двух словах: Выбранная схема работы:
1. позволяет размазать нагрузку между СКЛ и сервером бизнес-логики Аксапты
2. предполагается, что десяток простых, похожих друг на друга запросов лучше, чем пара сложных и уникальных (см. кэширование, предварительная компиляция, cost ompimizer, параметрические запросы и т.п.)
3. предполагается, что сервер бизнес-логики достаточно часто прерывает получение результатов запроса после получения части (исходя из своей бизнес-логики)
4. изначально разработчики очень большое внимание уделяли кросс-платформенности и возможности работы с различными СУБД (изначально была возможность работы и с Oracle, и c MS SQL, и mySQL, и с Postgree, и с DB/2 и с собственным форматом и еще с десятком различных СУБД). Теперь...

IgorKps/ У меня нет претензий к Аксапте как таковой - у меня притензии к работе с конкретной СУБД, причем родной для нее, заметьте!
А Теперь народ считает MS SQL родной системой.
А ведь изначально Аксапта писалась в первую очередь для Оракла

Да, последние версии Аксапты в первую очередь пишутся и оптимизируются под MS SQL. Причем под MS SQL 2008.
Но совместимость никто не отменял.
Но у клиентов используются и старые версии.

В частности, ax3.0 была здорово прооптимизирована для MS SQL 2005.
В те времена, когда был MS SQL 2000, Аксапта еще не принадлежала Майкрософту и в первую очередь оптимизировалась под Оракл.
Опять же таки http://axapta.mazzy.ru/lib/names/

Возвращаясь к случаю Волочковой.
Вместо того, чтобы разобраться в истории, в источниках проблем, собрать статистику, запустить таки cost optimizer или таки полностью отдаться sintax optimizer'у, найти пути решения.... там сделали следующее: оставили рассинхронизированными Аксапту и СУБД (в результате Аксапта не знает о реальной структуре базы данных и не может ничего оптимизировать сама), не делают и ручную оптимизацию структуры (см. эти дикие индексы). Вручную вставляют кластерные индексы, которые приводят к постоянному сплиту страниц ДАННЫХ (при этом не понимают разницу между сплитом данных и сплитом индексов). Более чем уверен, что не делат анализ, не пересчитывают статистику на MS SQL (как и у остальных клиентов с подобным характером). Вместо того, чтобы заниматься делом идет крик о неправильных принципах и подходах.

IgorKВам не кажется, что это говорит о неправильной работе с MSSQL ?
У людей была задача - опеспечить работу с разными СУБД (с десятком разных СУБД).
Потом из-за маркетинговых соображений осталось две поддерживаемые СУБД.
В последних версиях Майкрософт ориентируется прежде всего на MS SQL. Но клиенты это увидят только начиная с версии ax2009 (именно поэтому belugin так много говорит об этом).

Еще раз:
1. я согласен, что выбранное решение - работа через курсоры и через ODBC - не самое идеальное.
2. Однако выбранное решение вполне удовлетворительно при тех предположениях и в тех условиях, которые были тогда (1996-2002 годы).
3. я утверждаю, что выбранное решение - не приводит к таким катастрофическим последствиям как у Волочковой. К таким катастрофическим последствиям приводят безалаберность и безграмотность самих шпециалистов. Но даже в таких клинических случаях, как у Волочковой, нормальные могут и должны сделать так, чтобы Аксапта работала приемлемо для бизнеса: сбор статистики, оптимизация запросов, работа над индексами, нормальный maintanance plan и т.п. (ежедневынй ребилд индексов - это неприемлемо, кластерный индекс в таблице inventSum - это вредительство со стороны "шпециалистов").
4. Эволюция не остановилась. Работа над Аксаптой продолжается. Начало изменения принципов и предположений клиенты увидят в ax2009, которая уже вышла. Аксапта будет изменяться и развиваться дальше согласно утвержденным планам.

sobolev1. DynAx не всегда (мягко говоря) правильно работает с СУБД.
Да, предположения, сделанные в маленькой базе могут не оправдаться в большой, и наоборот.

sobolev
2. Требуется не мало "колдовства" (в статье целое исследование приведено) чтобы эту дорогую систему (еще один из тезисов Волочковой) заставить правильно работать.

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

Обратите внимание, что Аксапта предоставляет необходимые инструменты для администратора уличного мага.

sobolev
Если не ошибаюсь, в статье речь идет о корректировке кодов, написанных собственно разработчиками продукта, а не "кривыми" кастомайзерами.

Да. Но обратите внимание на дату публикации
Также обратите внимание, что подобная уличная магия доступна любому более-менее вменяемому специалисту-аксаптоведу.

sobolevСовсем все запуталось: чтобы система хорошо работала ее надо "готовить", но делать это должны сторонние шпециалисты, которые, в свою очередь, как правило (если я верно уловил дух высказываний опытных специалистов), все только портят.
Чтобы система хорошо работала и при размере 5Гб, и при размере 500Гб, ее надо тюнить, как и любую другую систему.
Делать это должны Специалисты (нормальные специалисты). Все равно какие - внутренние или внешние.
"Шпециалисты" вместо того, чтобы работать в согласии с системой, перестают синхронизировать Аксапту с СУБД, вносят коррекции в базу, не согласовывая с Аксаптой, делают безумные кластерные индексы. Скорее всего, перестают считать статистику. А потом начинают говорить о том, что их спасает только ежедневный полный ребилд индексов.

sobolevmazzy
Что ж, первый шаг в РЕШЕНИЮ проблем описан здесь http://axapta.mazzy.ru/lib/querytuning/

Мне показалось, что статья все-таки подтверждает ряд тезисов Волочковой. А именно:

Поэтому статья может таки подтверждает ряд тезисов.
Но указывает совершенно другой путь.

SeVaавторПерая волна прошла...Потихоньку все переводится на Net
Интересуют официальные источники, а не картинки с форума.Если ли таковые?Проект задвинут в долгий ящик или нет?
есть. ссылки на них собраны на форуме. если не устраивает форум, то ищите ссылки самостоятельно.
нет, проект не задвинут. он идет себе дальше.
просто сейчас он не называется Project Green, сейчас он просто Microsoft Dynamics.

Volochkova
Сколько примеры приводил, сколько писал, что проблема не у меня. Ну 3.5 у меня Косяпта и что?
У вас проблема, у вас. Нет такой версии
http://forum.mazzy.ru/index.php?showtopic=881

George NordicmazzyУ вас проблема, у вас. Нет такой версии

Полагаю, имелась в виду MBS Axapta 3.0 Sp 5.

Во-первых, было четыре разных выпуска, которые можно назвать SP5 (один международный, два российских FP и kernel rollup).
Во-вторых, говорю же "шпециалист", которому все равно... Один хрен виновата "Косяпта"