AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 20.01.2011, 14:10   #21  
mifi is offline
mifi
Microsoft Dynamics
Сотрудники Microsoft Dynamics
 
173 / 89 (3) ++++
Регистрация: 24.07.2002
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Дык с этим же никто и не спорит. Я ж тоже утрировал немного. Просто вот совершенно недавно видел ситуацию, что сотрудник клиента (система уже давно работает в промышленной эксплуатации и активной разработки не ведется) изменил некий код, при этом никто из сотрудников не знал всех мест где аукнется это изменение (чтобы не быть голословным - скажу - что изменили длину поля, и не знали в каких из хранимых процедур, не относящихся к штатной поставке АХ нужно произвести соответствующие изменения). И они решили оставить такую ситуацию, зная, что где-нибудь это вылезет. И это вылезло. И это поправили. А нашли нужное место отладчиком. Прямо на рабочей базе в рабочем процессе.
Конечно - данный подход заведомо неприменим к софтверной компании. Однако - он вполне устраивает клиента, т.к. в этом случае время, потраченное на исправление (пусть и в "горячем" режиме) на порядок меньше времени, потраченного бы на тестирование. А рабочий процесс позволяет выполнить данную процедуру в "горячем" режиме.
Другого клиента такой подход мог бы и не устроить - у него стоимость простоя могла быть выше стоимости тестирования.
В этом и гибкость системы - она устраивает двух клиентов. При запрете отладки на рабочей БД - один клиент из этих двух может отпасть - что приведет к уменьшению количества клиентов АХ (а мы, специалисты - в этом явно не заинтересованы).
Давайте все-таки разделять две вещи - максимально быстро фиксить баги и дебагить на рабочей версии.
Клиенту нужно первое. А второе - это только один из способов.
Еще раз повторю - внедренец профессионал внедрения, не клиент. Его обязанность объяснить, обучить, организовать.
Что мешает настроить резервное копирование так, чтобы иметь тестовое приложение с актуальными данными (если клиент-таки разрешает к ним доступ) и проводить хотя бы минимальное тестирование? Не проще, чем потом сотни джобов писать для правки багов в реальных данных?
Старый 20.01.2011, 14:32   #22  
BOAL is offline
BOAL
Участник
Аватар для BOAL
MCBMSS
Злыдни
1C
Лучший по профессии 2015
 
619 / 453 (17) +++++++
Регистрация: 28.04.2003
Адрес: Москва
Цитата:
Сообщение от mifi Посмотреть сообщение
Давайте все-таки разделять две вещи - максимально быстро фиксить баги и дебагить на рабочей версии.
Клиенту нужно первое. А второе - это только один из способов.
Еще раз повторю - внедренец профессионал внедрения, не клиент. Его обязанность объяснить, обучить, организовать.
Что мешает настроить резервное копирование так, чтобы иметь тестовое приложение с актуальными данными (если клиент-таки разрешает к ним доступ) и проводить хотя бы минимальное тестирование? Не проще, чем потом сотни джобов писать для правки багов в реальных данных?
Клиент сам решит - если есть выбор!

Иногда повтор ситуации займет 2-4ч реала или бакап Террабайтной базы ( это тоже не 1 час) + останов системы на Х часов.
Речь о том, что система отладки нужна на любой версии, а вот как ее применять (запрещать) - это осознанная методология внедрения\эксплуатации.
Но инструмент должен быть!
Это как шуроповерт или простая отвертка дома - она нужна не всегда, но бывает момент... и опа, она есть, а не нужно идти к соседу, а потом ее нести обратно.

Вот и тут так же - это все (отладка на рабочей) не нужно и нештатно - но это должно быть в ассортименте.

Просто в проекте есть моменты, когда это уж очень нужно и становится штатным (опытная эксплуатация на 1-3 недели).

Но и да, кто сам на клиенте не просидел и в глаза пользователям не смотрел (не абстрактным сотрудникам Заказчика, а конкретной Марье Ивановне), тот это все через себе не пропустит и другую точку зрения просто не поймет, а только проанализирует, смоделирует, прикинет и сделает выводы (надеюсь не "а и так сойдет", как обычно).
Че уж говорить о "теоретиках", которые даже глаз внедренца не видят

Последний раз редактировалось BOAL; 20.01.2011 в 14:35.
Старый 20.01.2011, 14:35   #23  
AlGol is offline
AlGol
Участник
 
277 / 93 (4) ++++
Регистрация: 24.12.2001
Адрес: Тверь.
Цитата:
Сообщение от mifi Посмотреть сообщение
Фед, почему минимальное использование best practices внедрения и поддержки (такое, как использование тестового приложения) вызывает такое отторжение?
Честное слово - я бы таким внедренцам, дебажащим на рабочем приложении, что-нибудь бы поотрывал
Использование нескольких последовательности приложений для разработки и тестирования никто, естественно, не отменял. Разрабатывать нужно на разработческой, а тестировать на тестовой версии приложения.

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

Я так прикидываю, что без возможности дебага на рабочей версии, время обратотки особо заковыристых вопросов может подскочить на тысячи процентов сразу.
Такой запрос вылезает может и раз в год, но по закону подлости это бывает или прямо перед сдачей налоговой отчетности или когда идет вал отгрузок перед праздниками.
Старый 20.01.2011, 14:47   #24  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от BOAL Посмотреть сообщение
Но и да, кто сам на клиенте не просидел и в глаза пользователям не смотрел (не абстрактным сотрудникам Заказчика, а конкретной Марье Ивановне), тот это все через себе не пропустит и другую точку зрения просто не поймет, а только проанализирует, смоделирует, прикинет и сделает выводы (надеюсь не "а и так сойдет", как обычно).
Че уж говорить о "теоретиках", которые даже глаз внедренца не видят
Все верно - но не следует уж прям так с ходу наезжать на МС. Там же тоже люди

Цитата:
Сообщение от mifi Посмотреть сообщение
Давайте все-таки разделять две вещи - максимально быстро фиксить баги и дебагить на рабочей версии.
Клиенту нужно первое. А второе - это только один из способов.
Все так, с уточнением, что под фразой "фиксить баги" мы понимаем:
- исправления в коде ошибок, не выявленных на тестировании
- неверную настройку каких-то параметров (в этом случае можно как ошибку считать отсутствие информативного сообщения об этом)
- ошибки самих пользователей, на которые не сделана "защита от дурака" или которые невозможно защитить "от дурака".

Цитата:
Сообщение от mifi Посмотреть сообщение
Еще раз повторю - внедренец профессионал внедрения, не клиент. Его обязанность объяснить, обучить, организовать.
Что мешает настроить резервное копирование так, чтобы иметь тестовое приложение с актуальными данными (если клиент-таки разрешает к ним доступ) и проводить хотя бы минимальное тестирование? Не проще, чем потом сотни джобов писать для правки багов в реальных данных?
Конечно можно все организовать. Но, повторюсь, - не все может вылезти на тестовой базе. Ярким примером могут быть ситуации, которые завязаны на интеграцию АХ с чем-либо.
Опять-таки:
- на тестовой базе нельзя (сложно = дольше) выявить ошибки пользователя
- на тестовой базе нельзя (сложно = дольше) выявить изменение настроек, выполненных ответственными за это сотрудниками, которые отнеслись безответственно к смене настроек
__________________
Возможно сделать все. Вопрос времени
Старый 20.01.2011, 15:14   #25  
mifi is offline
mifi
Microsoft Dynamics
Сотрудники Microsoft Dynamics
 
173 / 89 (3) ++++
Регистрация: 24.07.2002
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Все верно - но не следует уж прям так с ходу наезжать на МС. Там же тоже люди


Все так, с уточнением, что под фразой "фиксить баги" мы понимаем:
- исправления в коде ошибок, не выявленных на тестировании
- неверную настройку каких-то параметров (в этом случае можно как ошибку считать отсутствие информативного сообщения об этом)
- ошибки самих пользователей, на которые не сделана "защита от дурака" или которые невозможно защитить "от дурака".



Конечно можно все организовать. Но, повторюсь, - не все может вылезти на тестовой базе. Ярким примером могут быть ситуации, которые завязаны на интеграцию АХ с чем-либо.
Опять-таки:
- на тестовой базе нельзя (сложно = дольше) выявить ошибки пользователя
- на тестовой базе нельзя (сложно = дольше) выявить изменение настроек, выполненных ответственными за это сотрудниками, которые отнеслись безответственно к смене настроек
В общем, все так За исключением того, что на тестовой базе нельзя или сложно или существенно дольше выявить ошибки. Не беря в учет интеграцию (где эти ошибки могут быть "с другой стороны", поэтому в Аксе особо и не подебагишь), то почему на тестовой базе это будет существенно дольше (думаю, что в отличие от BOAL Вы в курсе, что совсем необязательно каждый раз делать полный бэкап терабайтной базы, поэтому получить слепок рабочей базы за полчаса-час вполне реально)
Старый 20.01.2011, 15:27   #26  
BOAL is offline
BOAL
Участник
Аватар для BOAL
MCBMSS
Злыдни
1C
Лучший по профессии 2015
 
619 / 453 (17) +++++++
Регистрация: 28.04.2003
Адрес: Москва
А меня вот парят эти вот пол-часа - час, там где их раньше не было вообще (1-5 мин или 60 мин -это все же х12-60 разницы, при этом эти 5 мин еще и на тесте тратить). Да и выгружать по-живому куски таблиц тоже работа. То есть в ущерб чему-то или спец чел. И кто сказал, что в Тб базе эти нужные куски тоже не маленькие - вдруг там контрольный пример как раз неверная сумма на кучи данных?

В общем, выжить будет можно, станет сложнее на пустом месте, дольше в суппорте, а значит выше цена владения. И сложности (отпугивание) при продажах.

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

Электрорубанком при определенном усердии (таком же, как ты, Миша, предлагаешь) и с выключенном электричеством можно строгать

Цитата:
Все верно - но не следует уж прям так с ходу наезжать на МС. Там же тоже люди
Да не, все ясно, все помнят, как было и пугаются, как стало (станет).
Тут скорее "мне за державу обидно"(С) В смысле систему.
Старый 20.01.2011, 15:32   #27  
SolNik is offline
SolNik
Участник
 
58 / 36 (2) +++
Регистрация: 22.10.2003
Речь не идет о разработке на рабочем окружении. Речь идет о поиске и выявлении причин неадекватного поведения продуктива системы.
Особенно это актуально на запуске системы.
Если такой возможности не будет в новой версии - это будет катастрофа.
Кстати в основном потребность трейсинга для выяснения причин невнятных сообщений об ошибках или что еще хуже - трассировок стека - это "сюрпризы" от MS из-за некачественного тестирования нового функционала.
На одном проекте из-за багов в стандарте в новом функционале многопоточного сводника в 2009 под угрозой оказалось продолжение эксплуатации системы.
Весь функционал тестировался перед запуском, но баг вылез только на больших объемах.
Если бы в этот момент (когда под угрозой стояла поставка в магазины на следующий день) мы предложили сделать копию рабочей базы и не спеша там поискать причину ошибки - проект бы точно остановили.
За это сообщение автора поблагодарили: AlGol (2), macklakov (2), sukhanchik (2).
Старый 20.01.2011, 15:33   #28  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от mifi Посмотреть сообщение
В общем, все так За исключением того, что на тестовой базе нельзя или сложно или существенно дольше выявить ошибки. Не беря в учет интеграцию (где эти ошибки могут быть "с другой стороны", поэтому в Аксе особо и не подебагишь), то почему на тестовой базе это будет существенно дольше (думаю, что в отличие от BOAL Вы в курсе, что совсем необязательно каждый раз делать полный бэкап терабайтной базы, поэтому получить слепок рабочей базы за полчаса-час вполне реально)
Про тестовую базу BOAL так сказал по одной простой причине. Если использовать тестовую базу, как буфер перед переносом модификаций на рабочую, то нельзя вести копию рабочей БД "чисто для суппорта".
Я не очень помню - отменяли ли правило "разрешенных трех приложений" в лицензионной политике - но если не отменяли - то нет возможности так плодить базы.
А если есть возможность, то получается нужно иметь помимо рабочей БД еще:
- разработческую
- тестовую
- демонстрационную (для обучения новых пользователей)
- суппортную (которая постоянно обновляется)

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

По поводу интеграции. Ошибки могут быть где угодно. И в АХ в том числе. А вот для выявления этих ошибок как ни крути нужен дебаггер. Особенно - если ошибка не на стороне АХ.

А более долгое выявление ошибок связано с тем, что пользователь только только вводит новые данные, которых еще нет в "суппортной" базе. И просит консультации "что у него не так". И тут очень сильно пригождается дебаггер, который позволяет быстро(!) выявить проблему отдельно взятого пользователя, чтобы сказать - ты сам виноват - не указал то-то и то-то. После чего дать задание программистам чтобы они эту ситуацию "обрамили" в адекватное сообщение (если это возможно).
__________________
Возможно сделать все. Вопрос времени
Старый 20.01.2011, 15:37   #29  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от SolNik Посмотреть сообщение
На одном проекте из-за багов в стандарте в новом функционале многопоточного сводника в 2009 под угрозой оказалось продолжение эксплуатации системы.
Весь функционал тестировался перед запуском, но баг вылез только на больших объемах.
Вот! Отличный пример! Не протестируешь такое на тестовой базе, ну никак!
А если баг проявляется только в многопользовательском варианте? Всех загонять в тестовую? Утопия это.

Просто скорее всего все это кончится тем, что отладку будут включать на рабочей БД, клиенты будут мучаться с производительностью, а в МС гадать - а чем же производительность АХ их не устраивает.
__________________
Возможно сделать все. Вопрос времени
Старый 20.01.2011, 15:39   #30  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
пересмотрите видео - отладка там есть
Старый 20.01.2011, 15:47   #31  
mifi is offline
mifi
Microsoft Dynamics
Сотрудники Microsoft Dynamics
 
173 / 89 (3) ++++
Регистрация: 24.07.2002
Цитата:
Сообщение от belugin Посмотреть сообщение
пересмотрите видео - отладка там есть
А это же вроде с самого начала было понятно, об ее отсутствии заявил Фед, а не Питер С Густаво Я-то просто удивился, что это такая сверхнужная фича
Старый 20.01.2011, 15:52   #32  
mifi is offline
mifi
Microsoft Dynamics
Сотрудники Microsoft Dynamics
 
173 / 89 (3) ++++
Регистрация: 24.07.2002
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
А более долгое выявление ошибок связано с тем, что пользователь только только вводит новые данные, которых еще нет в "суппортной" базе. И просит консультации "что у него не так". И тут очень сильно пригождается дебаггер, который позволяет быстро(!) выявить проблему отдельно взятого пользователя, чтобы сказать - ты сам виноват - не указал то-то и то-то. После чего дать задание программистам чтобы они эту ситуацию "обрамили" в адекватное сообщение (если это возможно).
О чем говорит данный сценарий? На мой взгляд, как раз о том, что пользователь начал использовать новую функциональность без тестирования и пользовательских процедур. Ввел что ему в голову взбрело. И это хорошо, если он попросил консультации "что у него не так". А если забил/не обратил внимание и наплодил таких данных за месяц, прежде чем ошибка обнаружилась?
Старый 20.01.2011, 16:01   #33  
greench is offline
greench
Участник
Oracle
 
425 / 74 (3) ++++
Регистрация: 12.07.2007
Адрес: Киев
Многие действительно забывает о существовании разработчиков у самого клиента. Я работал и в консалтинговой компании и на клиенте. У внедренца есть время все протестить и перепроверить. На клиенте обычно происходило так: какой-нибудь пользователь что-то отчебучил в системе, что-то поломалось, и он побежал жаловаться начальству. И все, куча писем, телефоны обрывают, нужно решить проблему быстро. А когда еще и генеральный прибегает с пеной у рта...

И организация процесса разработки на клиенте немного другая. Очень часто ТЗ никто не пишет, документации как таковой в природе не существует или осталась устаревшая от внедренца и тд...

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

Так что иногда дебаг на боевом приложении иногда очень нужен первой линии обороны. И говорить что они криволапые и руки им нужно оторвать... ну не совсем разумно наверное.
Старый 20.01.2011, 16:01   #34  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от mifi Посмотреть сообщение
А это же вроде с самого начала было понятно, об ее отсутствии заявил Фед, а не Питер С Густаво Я-то просто удивился, что это такая сверхнужная фича
Фича - сверхнужная, смех здесь неуместен. Другое дело, что использовать ее надо как можно реже и как можно короче из-за опасности блокировок в многопользовательском режиме.
Старый 20.01.2011, 16:08   #35  
mifi is offline
mifi
Microsoft Dynamics
Сотрудники Microsoft Dynamics
 
173 / 89 (3) ++++
Регистрация: 24.07.2002
Цитата:
Сообщение от greench Посмотреть сообщение
Многие действительно забывает о существовании разработчиков у самого клиента. Я работал и в консалтинговой компании и на клиенте. У внедренца есть время все протестить и перепроверить. На клиенте обычно происходило так: какой-нибудь пользователь что-то отчебучил в системе, что-то поломалось, и он побежал жаловаться начальству. И все, куча писем, телефоны обрывают, нужно решить проблему быстро. А когда еще и генеральный прибегает с пеной у рта...

И организация процесса разработки на клиенте немного другая. Очень часто ТЗ никто не пишет, документации как таковой в природе не существует или осталась устаревшая от внедренца и тд...

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

Так что иногда дебаг на боевом приложении иногда очень нужен первой линии обороны. И говорить что они криволапые и руки им нужно оторвать... ну не совсем разумно наверное.
Перечитайте еще раз текст моего сообщения, про кого именно я это написал Понятно, что если ситуация как вышеописанная - то деваться некуда и людей с этой первой линии обороны никто ни в чем не винит
Старый 20.01.2011, 16:10   #36  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от mifi Посмотреть сообщение
О чем говорит данный сценарий? На мой взгляд, как раз о том, что пользователь начал использовать новую функциональность без тестирования и пользовательских процедур. Ввел что ему в голову взбрело. И это хорошо, если он попросил консультации "что у него не так". А если забил/не обратил внимание и наплодил таких данных за месяц, прежде чем ошибка обнаружилась?
Как один вариантов - да, согласен. Хотя никто осознанно бред не вводит. Всегда есть обоснование почему именно так он сделал.
Дело-то в другом. Внедренец (если это сторонняя фирма) сможет сделать такие выводы только после анализа кода в отладчике (если такая ситуация конечно возникла первый раз).
Или же нанятый сотрудник клиента, малознакомый с функциональностью также не сможет быстро выяснить причины проблемы без отладки.

Но... главный вопрос. МС заинтересован в увеличении числа таких клиентов? Ведь в результате "действования по науке" фирма будет иметь уже бизнес-проблемы, а ведь обвинят в первую очередь систему и именно от нее будут стремиться отказаться.

При грамотном подходе можно и SQL Server затюнить и 1С заставить летать и много чего еще. Мы все выбираем соотношение цена/качество - и не стремимся купить бентли для поездки на дачу. Так почему же МС заставляет отказываться от АХ?
__________________
Возможно сделать все. Вопрос времени
Старый 20.01.2011, 16:13   #37  
greench is offline
greench
Участник
Oracle
 
425 / 74 (3) ++++
Регистрация: 12.07.2007
Адрес: Киев
Так никто никого ничего не заставляет. Уже выяснили что дебаг на боевой никто не отменяет. Пошла больше дискуссия в стиле "за жизнь поговорить"
Старый 20.01.2011, 16:18   #38  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от BOAL Посмотреть сообщение
Пусть это нужно 1 раз в год на 10мин, но это экономит эти 3.65 дня дауна системы.
Цитата:
Сообщение от EVGL Посмотреть сообщение
Другое дело, что использовать ее надо как можно реже и как можно короче из-за опасности блокировок в многопользовательском режиме.
А никто и не говорит ее использовать направо и налево. Это как пожарный кран. Быть должен и в рабочем состоянии. В экстренных случаях включать. Т.е. по возможности, конечно нужно избегать мучания рабочей БД. Но опять-таки - в разумных пределах. Т.е. если отладка на рабочей в текущей ИТ-инфраструктуре будет существенно быстрее иных способов поиска причин проблемы - то вполне можно воспользоваться.
__________________
Возможно сделать все. Вопрос времени
Старый 20.01.2011, 16:24   #39  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от greench Посмотреть сообщение
Так никто никого ничего не заставляет. Уже выяснили что дебаг на боевой никто не отменяет. Пошла больше дискуссия в стиле "за жизнь поговорить"
Все отсюда пошло:
Цитата:
Сообщение от fed Посмотреть сообщение
А еще реальностью стал (по моим источникам) геморрой с перезагрузкой откомпилированных сборок. То есть - либо рестарт боевого AOS, либо работа через Application Domain. Причем скорость второго режима, мягко говоря, бледно смотриться даже на фоне скорости старого интерпретатора.
Ооо - почитал твиттер Брендона:
1. Отладка на сервере возможна только через VS Debugger
2. Чтобы отлаживаться, придется включать App Domain с тормозами.
3. Если у тебя на сервере работает несколько разработчиков - опять таки только App Domain с hot-swapping.
Т.е. при выборе системы все расписывают как она будет летать. МС готовит кучу тестов естественно без режима отладки.
В жизни получается (клиент делает такой вывод или ему помогают сделать такой вывод) что режим отладки (Application Domain) должен быть постоянно включен на рабочей БД, что влияет на скорость работы.
У клиента наступает разочарование и полное желание отказаться от такой системы (если хватает денег ).
Клиент меняет систему и имеет систему если не лучше то по крайней мере дешевле.
Клиент всем своим знакомым рассказывает - какой отстой - АХ - и ни в коем случае не работайте с МС - там нет компетентных людей.
__________________
Возможно сделать все. Вопрос времени
Старый 20.01.2011, 16:35   #40  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Отлаживаться можно без APPDomain насколько я знаю.

Горячую замену нужно проводить через APPDomain.
За это сообщение автора поблагодарили: Logger (1).
Теги
ax2012

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
отладка Web приложений egorych DAX: Программирование 11 06.06.2007 18:26
Подружить Россию и Латвию - в российской базе Латвийская дочка Raven Melancholic DAX: Администрирование 4 21.11.2006 13:36
Список полей таблиц на базе конкретного EDT Владимир Максимов DAX: Программирование 10 06.10.2004 14:45
Разрешение на доступ к базе данных nicko DAX: Администрирование 3 18.05.2004 18:49
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 17:10.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.