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

Нужна, вот только данных в ней не хватает... ((. Долго объяснять, короче говоря:)

страшная конфигурация если система есть, но не используется, так как данных не хватает...

для таких целей существует копирование продуктивного манданта (вместе с данными) в QAS, так как все равно разработчики в продуктиве сидят, например, сокращая драгоценные D-процессы сервера...

Если нет полномочий на изменение контекста в отладчике,то хакерство не пройдет.Отладка в продуктиве есть зло с точки зрения производительности.

просто если нет полномочий на S_DEVELOP и операцию 03 система->статус не спасет.
У нас разработчику в тестовую систему сходить - целая эпопея. Я писал об этом в http://sapboard.ru/forum/viewtopic.php?t=17781

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

Ну и это... при небольшом или большом желании можно обойти, знаешь ли были случаи когда было надо

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

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

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

Если речь идет про "вынос" разработок из продуктива, то это более гуманный случай, чем вести отладку в продуктиве. Более того, переносить объекты может (и должен бы) вполне определенный человек.


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

А откатить версию?
Зачем в продуктив для этого залезать?

На самом деле, я ситуацию с умыслом описал, чтобы узнать мнения коллег о правильности такого подхода.
По сравнению в программированием в Visual Studio, не хватает такого продукта, как SourсeSafe для контроля измененния в исходных текстах. Вот и хотел узнать, какие возможны варианты откатов изменений.

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

в SAP разработка ведется ЦЕНТРАЛИЗОВАНО, поэтому проблемы с синхронизацией разработок не существует, а получить доступ к предыдущим объектам репозитария можно через "перейти к" - "управление версиями"

Tetty, возможность управления версиями в SAP мне настолько понравилась, что лично сам предпочитаю предварительно сохранять тексты на жестком диске, с последующим удобным поиском через Far

это уж точно))