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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 20.01.2011, 08:17   #1  
mifi is offline
mifi
Microsoft Dynamics
Сотрудники Microsoft Dynamics
 
173 / 89 (3) ++++
Регистрация: 24.07.2002
Отладка на рабочей базе
*** sukhanchik Выделено из DeniZone: The future of X++ ***
Цитата:
Сообщение от fed Посмотреть сообщение
Ооо - как новую систему полюбят все внедренцы ! Ведь теперь нельзя будет отлаживаться на боевом сервере. Придется мучительно допрашивать пользователей о том, что же они такого отмочили и потом пытаться воспроизвести на тестовом приложении. Разумеется с подъемом бэкапа БД.
Фед, почему минимальное использование best practices внедрения и поддержки (такое, как использование тестового приложения) вызывает такое отторжение?
Честное слово - я бы таким внедренцам, дебажащим на рабочем приложении, что-нибудь бы поотрывал

Последний раз редактировалось sukhanchik; 20.01.2011 в 12:01.
За это сообщение автора поблагодарили: farlander (1).
Старый 20.01.2011, 08:32   #2  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от fed Посмотреть сообщение
А еще реальностью стал (по моим источникам) геморрой с перезагрузкой откомпилированных сборок.
1. Отладка на сервере возможна только через VS Debugger
2. Чтобы отлаживаться, придется включать App Domain с тормозами.
3. Если у тебя на сервере работает несколько разработчиков - опять таки только App Domain с hot-swapping.
Вроде Понтоппидан ясно написал, что по умолчанию выполнение приложения в виде IL-кода средствами CLR включено лишь для пакетников, вызовов каких-то сервисов и отдельных кусков приложения, на которые явно указали разработчики посредством RunAs. Я лично сразу вспомнил про "особенности" отладки кода в NAV 2009 (пишешь на одном языке, отлаживаешь на другом) и подумал, что так сделали именно из-за отладки: пакетники отлаживают не так часто (по крайней мере, именно в режиме выполнения на сервере), но при этом на них может приходиться существенная доля нагрузки на систему, поэтому для них и включили по умолчанию новый механизм исполнения кода, а для бизнес-логики, запускаемой пользователями, - выключили, чтобы ее можно было при необходимости отлаживать, как обычно.
Цитата:
Сообщение от mifi Посмотреть сообщение
почему минимальное использование best practices внедрения и поддержки (такое, как использование тестового приложения) вызывает такое отторжение?
По-моему, best practices не избавляют полностью от необходимости время от времени отлаживаться на рабочем приложении. У всех, видимо, масштаб времени свой: кто-то может себе позволить для теста развернуть бэкап рабочей базы (извиняюсь за нескромный вопрос, на какого размера базе вы тестируете обычно?) и пару дней вдумчиво исследовать произошедшее, а кому-то нужно ответить пользователю, что за фигня, в течение максимум часа.
За это сообщение автора поблагодарили: Logger (2).
Старый 20.01.2011, 09:10   #3  
mifi is offline
mifi
Microsoft Dynamics
Сотрудники Microsoft Dynamics
 
173 / 89 (3) ++++
Регистрация: 24.07.2002
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Вроде Понтоппидан ясно написал, что по умолчанию выполнение приложения в виде IL-кода средствами CLR включено лишь для пакетников, вызовов каких-то сервисов и отдельных кусков приложения, на которые явно указали разработчики посредством RunAs. Я лично сразу вспомнил про "особенности" отладки кода в NAV 2009 (пишешь на одном языке, отлаживаешь на другом) и подумал, что так сделали именно из-за отладки: пакетники отлаживают не так часто (по крайней мере, именно в режиме выполнения на сервере), но при этом на них может приходиться существенная доля нагрузки на систему, поэтому для них и включили по умолчанию новый механизм исполнения кода, а для бизнес-логики, запускаемой пользователями, - выключили, чтобы ее можно было при необходимости отлаживать, как обычно.
По-моему, best practices не избавляют полностью от необходимости время от времени отлаживаться на рабочем приложении. У всех, видимо, масштаб времени свой: кто-то может себе позволить для теста развернуть бэкап рабочей базы (извиняюсь за нескромный вопрос, на какого размера базе вы тестируете обычно?) и пару дней вдумчиво исследовать произошедшее, а кому-то нужно ответить пользователю, что за фигня, в течение максимум часа.
В ответ на вопрос пользователя нужно дать правильный ответ.У меня есть подозрение, что достаточно существенный процент ответов (а тем более фиксов), сделанных "в течение максимум часа" приведут, извиняюсь, к еще большей фигне.Которую доблестный внедренец продолжит дебажить на рабочем приложении. На 99% внедрений, с которыми я работаю, разработчик вообще не имеет доступа к рабочей базе, поэтому вопрос о ее размере не имеет особого значения.

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

Человек с должностью "разработчик" может и не иметь доступ к рабочему приложению. Но опять-таки - кто-то, кто обладает знаниями Х++ кода должен иметь возможность понять проблему пользователя, которая:
а) может быть нечетко сформулирована (ну не помнит пользователь сколько кликов и куда в точной последовательности он сделал)
б) может воспроизводиться только на рабочей БД (в силу отсутствия актуальных данных на копии рабочей БД), а время создание актуальной копии тестовой БД больше требуемого времени на решение проблемы
в) может в принципе не воспроизводиться на любой БД кроме рабочей

Более того, на некрупных внедрениях экономически может быть выгоднее вместо тщательного тестирования перенос кода на рабочее приложение с собиранием "граблей" в рабочем режиме UPD: Конечно это для редких модификаций. Но которые все же могут присутствовать.
__________________
Возможно сделать все. Вопрос времени

Последний раз редактировалось sukhanchik; 20.01.2011 в 10:12.
Старый 20.01.2011, 10:31   #5  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
вроде в видео была отладка X++ на VS
Старый 20.01.2011, 11:45   #6  
mifi is offline
mifi
Microsoft Dynamics
Сотрудники Microsoft Dynamics
 
173 / 89 (3) ++++
Регистрация: 24.07.2002
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Из возможности отладки на рабочем приложении не следует необходимость делания фиксов, которые "быстро заливаются". Отладка в большинстве случаев необходима чтобы разобраться в причине неадекватного поведения.
Сравните время поиска ответа в документации (которого в ней может не быть или он может быть сильно завуалирован) со временем прохода в отладчике и понимании что "кто-то не заполнил вот такое-то поле" или "кто-то выключил вот такую-то галку" или (в крайнем случае) "при написании и тестировании кода не учли такую-то ситуацию".

Человек с должностью "разработчик" может и не иметь доступ к рабочему приложению. Но опять-таки - кто-то, кто обладает знаниями Х++ кода должен иметь возможность понять проблему пользователя, которая:
а) может быть нечетко сформулирована (ну не помнит пользователь сколько кликов и куда в точной последовательности он сделал)
б) может воспроизводиться только на рабочей БД (в силу отсутствия актуальных данных на копии рабочей БД), а время создание актуальной копии тестовой БД больше требуемого времени на решение проблемы
в) может в принципе не воспроизводиться на любой БД кроме рабочей

Более того, на некрупных внедрениях экономически может быть выгоднее вместо тщательного тестирования перенос кода на рабочее приложение с собиранием "граблей" в рабочем режиме UPD: Конечно это для редких модификаций. Но которые все же могут присутствовать.
У нас пошел офф-топик от основной темы, поэтому предлагаю выделить данную подветку отдельно.
А насчет "экономически выгодно" - слов нет. Вроде как считается, торговля наркотиками - один из самых экономически выгодных видов деятельности. Но это же не значит, что всем нужно срочно на него переключаться?
Понятно, что если переносить нетестированный код (думаю, я правильно понял эвфемизм "вместо тщательного тестирования"), то потом надо будет судорожно дебагить рабочее приложение и фиксить все "максимум в течение часа"
Старый 20.01.2011, 11:49   #7  
BOAL is offline
BOAL
Участник
Аватар для BOAL
MCBMSS
Злыдни
1C
Лучший по профессии 2015
 
619 / 453 (17) +++++++
Регистрация: 28.04.2003
Адрес: Москва
Цитата:
Сообщение от mifi Посмотреть сообщение
Фед, почему минимальное использование best practices внедрения и поддержки (такое, как использование тестового приложения) вызывает такое отторжение?
Честное слово - я бы таким внедренцам, дебажащим на рабочем приложении, что-нибудь бы поотрывал
Потому, что разработчки софта (и часто его сотрудники) очень далекие от реальной работы системы люди - они теоретики.
Есть три категории опыта АХ
1. Разработка ядра и его локализации
2. Внедрение этой чудо-системы
3. Работа на клиенте.
Только тот, кто прошел 2 и 3 достоин заниматься 1
А у нас идут в 1 с улицы или в лучшем случае с парой лет 2 на ролях "сидел в трюме, общался с юзерами через консультанта".

Любая фича (хрень), которая коробит самого разраба, делает его тест содеянного им же, неудобным в течении 0.5 минуты и тем более более (5 мин или час!!) будет коробить конечного пользователя по 8ч в день все время!!!
А разараб - "покрасил и забыл"(С) (тут смотрим тему про цвета в гриде и тп)

Так вот - АХ еже версионно теряет свои конкурентные преимущества над другими системами. Внедренцы тоже не дураки и из монобизнеса становятся "ЕРП в ассортименте и, конечно, свежий 1С в наличии".

Перекрестные ссылки, которые перестанут работать на вынос части кода (отчетов и прочего) в ВижуалСтудию, отваливающийся от этого код, который даже компиляцией на найти, токо по факту неработы и падения в (синий экран видимо )
Отказ дебугера, стек4а вызовов и просмотра переменных на рабочей база == увеличению срока простоев системы с 5-10мин нонстоп отладки без выгона юзеров, до 3-24ч на всякие переносы бакапа и повтора ошибки.

Мы даже на пакетнике сча врубили стек вызовов - лезет там инфолог, зашел в пакетник, увидел "Ошибка" - перешел в код, хоть понял про что речь.

Мы ж все помним какие тексты ошибок выдвает АХ и что их нужно уметь читать и понимать, что если она пишет ХХХХ, то это вовсе не ХХХХ, а совсем даже УУУ.

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

Ведь 99% надежная система - это значит что в год она 3.65 дня стабильно лежит в дауне.
должно быть 99.999% - а это все из мелочей скалдывается.
Да и в конце концов - возможность, не значит нужно пользоваться. А нет возможности == танцы с бубном. Пусть это нужно 1 раз в год на 10мин, но это экономит эти 3.65 дня дауна системы.

Накипело, сорвался, выговарился, простите, если что не так
За это сообщение автора поблагодарили: mazzy (5), Alexius (2), AlGol (2), macklakov (5), raz (3), db (3), sukhanchik (5), Logger (1), lev (3), Daiver (1), Ivanhoe (5), gl00mie (3).
Старый 20.01.2011, 11:52   #8  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от mifi Посмотреть сообщение
Фед, почему минимальное использование best practices внедрения и поддержки (такое, как использование тестового приложения) вызывает такое отторжение?
Честное слово - я бы таким внедренцам, дебажащим на рабочем приложении, что-нибудь бы поотрывал
Ну это вы зря.
Некоторые деятели любят писать на рабочей и потом накатывать на дев. А некоторые забывают накатывать. Вот этим я бы руки точно оторвал
Старый 20.01.2011, 11:59   #9  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от mifi Посмотреть сообщение
В ответ на вопрос пользователя нужно дать правильный ответ.
Ваши бы слова да нашим юзерам в уши ! "Дать правильный ответ" - как праивло воспринимается как отмазка. Срабатывает не всегда

Цитата:
Сообщение от mifi Посмотреть сообщение
У меня есть подозрение, что достаточно существенный процент ответов (а тем более фиксов), сделанных "в течение максимум часа" приведут, извиняюсь, к еще большей фигне.Которую доблестный внедренец продолжит дебажить на рабочем приложении. На 99% внедрений, с которыми я работаю, разработчик вообще не имеет доступа к рабочей базе, поэтому вопрос о ее размере не имеет особого значения.
А у меня есть подозрение - что это снизит на порядки время поиска ошибки и улучшит сервис, предоставляемый клиенту, который платит деньги и заказывает музыку.
Главная задача ведь не в том чтобы исправить тяп ляп, а воспроизвести багу и разобраться в чем проблема была !
Старый 20.01.2011, 12:47   #10  
mifi is offline
mifi
Microsoft Dynamics
Сотрудники Microsoft Dynamics
 
173 / 89 (3) ++++
Регистрация: 24.07.2002
Цитата:
Сообщение от Logger Посмотреть сообщение
Ну это вы зря.
Некоторые деятели любят писать на рабочей и потом накатывать на дев. А некоторые забывают накатывать. Вот этим я бы руки точно оторвал
В общем, если писать все сразу на рабочей версии, то это, конечно, экономически еще более выгодно, можно ничего и не переносить да и вообще избавиться от всяких дев и тест версий.
Старый 20.01.2011, 12:55   #11  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от mifi Посмотреть сообщение
Понятно, что если переносить нетестированный код (думаю, я правильно понял эвфемизм "вместо тщательного тестирования"), то потом надо будет судорожно дебагить рабочее приложение и фиксить все "максимум в течение часа"
Тю!.. вот только не надо "ля-ля" про нетестированный код! Кто-то так хорошо тестировал RCashVoucher (в RU5, по крайней мере), что забыл обрамить обращения к RCashTrans в unchecked(Uncheck::TableSecurityPermission) (хотя Best Practices все знают и Writing Secure X++ Code, наверно, все читали - иначе с чего бы повесили AOSAuthorization на таблицу), из-за чего у пользователей без доступа к ключу RCashTables, но с доступом к самой таблице и всем формам не разносятся кассовые журналы.
За это сообщение автора поблагодарили: Daiver (1).
Старый 20.01.2011, 12:59   #12  
CDR is offline
CDR
MCTS
MCBMSS
 
236 / 175 (6) ++++++
Регистрация: 27.11.2003
Цитата:
Сообщение от mifi Посмотреть сообщение
На 99% внедрений, с которыми я работаю, разработчик вообще не имеет доступа к рабочей базе, поэтому вопрос о ее размере не имеет особого значения.
Наверное именно поэтому "локализованная" функциональность порой поражает своей производительностью.
__________________
Dynamics AX Experience
Старый 20.01.2011, 13:10   #13  
mifi is offline
mifi
Microsoft Dynamics
Сотрудники Microsoft Dynamics
 
173 / 89 (3) ++++
Регистрация: 24.07.2002
Цитата:
Сообщение от CDR Посмотреть сообщение
Наверное именно поэтому "локализованная" функциональность порой поражает своей производительностью.
Забавная дискуссия получилась. На утверждение, сопоставимое, на мой взгляд, по тривиальности с "Дети, чистите зубы утром и вечером " в ответ слышно, в основном "Вы там в МС к.. теоретики" В общем, подобная точка зрения тоже имеет право на существование, но зубы все-таки надо чистить/поддерживать рабочую, тестовую и разработческую версию
Старый 20.01.2011, 13:33   #14  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от mifi Посмотреть сообщение
В общем, если писать все сразу на рабочей версии, то это, конечно, экономически еще более выгодно, можно ничего и не переносить да и вообще избавиться от всяких дев и тест версий.
Ну, про разработку на рабочей и перенос на дев это шутка была.
Старый 20.01.2011, 13:35   #15  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от CDR Посмотреть сообщение
Наверное именно поэтому "локализованная" функциональность порой поражает своей производительностью.
Вы хотите всего и сразу.
Сначала скажите спасибо, что она вообще появилась.

Производительность, будем надеяться, потом допилят.

Кстати, почитал что нового в RU6 - в отличие от RU5 - нового почти ничего. В основном исправление ошибок и ускорение работы.
Старый 20.01.2011, 13:43   #16  
mifi is offline
mifi
Microsoft Dynamics
Сотрудники Microsoft Dynamics
 
173 / 89 (3) ++++
Регистрация: 24.07.2002
Цитата:
Сообщение от Logger Посмотреть сообщение
Ну, про разработку на рабочей и перенос на дев это шутка была.
То, что Вы шутили, я понял. Но, в общем, мне не очень весело. Единственная надежда, что только мой логотип вызвал отторжение идеи того, что разрабатывать и отлаживать надо на разработческой версии.

Последний раз редактировалось mifi; 20.01.2011 в 13:46.
Старый 20.01.2011, 13:51   #17  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Да никто не спорит что разрабатывать и отлаживать надо по науке. Пишем на дев, тестируем на тесте. Работаем на рабочей.
Но иногда просто необходимо на рабочей что нибудь отладить. К сожалению, иногда воспроизвести глюк на тесте - отдельная большая задача. Плюс не всегда есть уверенность что это тот же самый глюк. А на боевой удобно посмотреть, быстро ясна причина. Время реагирования на запрос снижается кардинально.

P.S.
Аксапта это, к сожалению, не iPhone 4
Её с руками не отрывают. И кризис в IT никуда пока не делся.
Надо думать как предоставить клиенту лучший сервис.

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

Последний раз редактировалось sukhanchik; 20.01.2011 в 14:01.
Старый 20.01.2011, 14:00   #19  
Zabr is offline
Zabr
Участник
Axapta Retail User
 
1,200 / 345 (14) ++++++
Регистрация: 26.06.2002
Адрес: Москва
Мнение и аргументы тех, кто работал только со стороны исполнителя, будут неполными. И тех, кто работал только у заказчика, тоже будут неполными. Только тот, кто работал и со стороны заказчика, и со стороны исполнителя, кто знает и теорию правильной разработки и реальную жизнь, смогут адекватно между собой обсуждать данную тему. Иначе будет разговор глухих со слепыми.
Имеет смысл вообще закрыть ветку.
Старый 20.01.2011, 14:03   #20  
mifi is offline
mifi
Microsoft Dynamics
Сотрудники Microsoft Dynamics
 
173 / 89 (3) ++++
Регистрация: 24.07.2002
Цитата:
Сообщение от Logger Посмотреть сообщение
Да никто не спорит что разрабатывать и отлаживать надо по науке. Пишем на дев, тестируем на тесте. Работаем на рабочей.
Но иногда просто необходимо на рабочей что нибудь отладить. К сожалению, иногда воспроизвести глюк на тесте - отдельная большая задача. Плюс не всегда есть уверенность что это тот же самый глюк. А на боевой удобно посмотреть, быстро ясна причина. Время реагирования на запрос снижается кардинально.

P.S.
Аксапта это, к сожалению, не iPhone 4
Её с руками не отрывают. И кризис в IT никуда пока не делся.
Надо думать как предоставить клиенту лучший сервис.

Если люди на ваши слова нервно реагируют, то это не логотип виноват, а наболело у них. А вы просто под руку подвернулись
Так в том-то и суть. Лучший сервис - профессиональный сервис. Клиент (обычно) не является экспертом в области внедрения ERP. Если ему рассказать как все надо правильно делать, то он сам запретит доступ разработчикам на рабочее приложение и проблема решиться сама собой Это, кстати, не теоретические измышления, а вполне реальные факты из моей практики
То, что следует сесть вместе с пользователем и посмотреть, что у него происходит - вроде как с этим никто не спорил. А вот дебагить разноску инвойса на терабайтной базе с парой сотен работающих пользователей.. хм.
Теги
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:17.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.