06.07.2017, 11:06 | #1 |
Участник
|
Изменения в Table Browser в последнем Platform Update 8
Видели, что теперь администраторы не смогут данные править через обозреватель таблиц на live environments?
Цитата:
Table browser is now in read-only mode
The table browser form is now in read-only mode on runtime environments (Sandbox Tier-2 and Production). The table browser form is designed for developers to quickly create and edit test data on development environments. It was also available to system administrators on runtime environments. As of Platform update 8, system administrators can only access the table browser in read-only mode on runtime environments, this is in reaction to live incidents caused by human error when system administrators inadvertently edited or removed live system data. |
|
06.07.2017, 11:20 | #2 |
Участник
|
О! Теперь я знаю какая будет самая первая модификация в системе !
Открыть на редактирвание / скопипастить SysTableBrowser |
|
06.07.2017, 11:21 | #3 |
Участник
|
Вставай на нано-лыжи
Садись за нано-книги На-на-на позитиве.... https://promodj.com/vengerov-fedorof...dio_Edit_Remix А чего ты обсудить хочешь? Это общая тенденция в МС - "куда они от нас денутся?" Денутся, конечно. На крайняк сделают свои браузеры. Сделали же. А запретили наверняка потому что где-то какие-то тесты не проходят и у разработчиков МС не хватает ресурсов, чтобы сделать по-человечески. вот и делают очередной workaround. |
|
06.07.2017, 11:23 | #4 |
Участник
|
ну... там теперь сложнее несколько. на ровном месте.
но я абсолютно не соменваюсь, что народ сделает. |
|
06.07.2017, 11:29 | #5 |
Участник
|
Цитата:
Table browser is now in read-only mode
Цитата:
Здесь не сказано "read-only mode only" Может, оно открывает в read-only, а потом можно переключить в нормальный режим? Ваня, можешь открыть и проверить? Мой текущий билд с Update8 возвращает ошибку при попытке открыть Table Browser из средств разработки. Но у меня сильно промежуточный билд... Поэтому ошибка ничего не значит. |
|
06.07.2017, 11:30 | #6 |
Участник
|
Цитата:
Они строят забор там, где в нем все равно проломят дыру и будут шастать туда и сюда. Потому что людям надо! Бессмысленно строить забор так где нужен проход. Правильнее было бы предусмотреть удобный механизм отката изменений. Например в оракл есть удобный механизм флешбека. Просто пишешь запрос X++: SELECT * FROM SCHEMA.TABLENAME /* AS OF TIMESTAMP TO_TIMESTAMP('2017-06-30 12:50:00', 'YYYY-MM-DD HH24:MI:SS') */ A WHERE ... Если к тебе прибежал испуганный программист/админ/юзер - то просто берешь и пишешь X++: SELECT * FROM SCHEMA.TABLENAME /* AS OF TIMESTAMP TO_TIMESTAMP('2017-06-30 12:50:00', 'YYYY-MM-DD HH24:MI:SS') */ A WHERE ... AND NOT EXISTS ( SELECT 'x' FROM SCHEMA.TABLENAME B WHERE ( SUBSTR(NLS_LOWER(B.DATAAREAID),1,4) = SUBSTR(NLS_LOWER(A.DATAAREAID),1,4) AND B.recid = A.recid ) ) Ну может выполняешь несколько раз этот запрос с перечнем полей count(*) на разную дату время чтобы поймать лучше момент времени с которого ндао взять удаленные впоследствии данные. И затем восстанавливаешь их X++: INSERT INTO SCHEMA.TABLENAME ( FIELD1, FIELD2 ... ) SELECT FIELD1, FIELD2 ... FROM SCHEMA.TABLENAME /* AS OF TIMESTAMP TO_TIMESTAMP('2017-06-30 12:50:00', 'YYYY-MM-DD HH24:MI:SS') */ A WHERE ... AND NOT EXISTS ( SELECT 'x' FROM SCHEMA.TABLENAME B WHERE ( SUBSTR(NLS_LOWER(B.DATAAREAID),1,4) = SUBSTR(NLS_LOWER(A.DATAAREAID),1,4) AND B.recid = A.recid ) ) Как бы в SQL Server штатно такое сделать ? Вроде до сих пор нельзя. |
|
06.07.2017, 11:33 | #7 |
Moderator
|
|
|
06.07.2017, 11:35 | #8 |
Участник
|
И не надо.
Точно по тем же причинам, почему не надо делать удаление и редактирование проведенных документов - в многопользовательской системе на основании отредактированных данных могут создать новые документы/данные. Откат/удаление/редактирование проведенных может нарушить целостность. Если речь идет о монопольном редактировании, то делать опасные изменения после создания бэкапа/снапшота базы, |
|
|
За это сообщение автора поблагодарили: Logger (3). |
06.07.2017, 11:43 | #9 |
Участник
|
Не надо ?
Вам не нужен инструмент, позволяющий за 10 минут восстановить систему после аварии ? Подъем бекапа может занять часы или сутки. LOL |
|
06.07.2017, 11:58 | #10 |
Участник
|
Цитата:
LOL Последний раз редактировалось mazzy; 06.07.2017 в 12:02. |
|
06.07.2017, 12:05 | #11 |
Участник
|
Цитата:
Сообщение от mazzy
И еще. А давай читать внимательно.
Здесь не сказано "read-only mode only" Может, оно открывает в read-only, а потом можно переключить в нормальный режим? Ваня, можешь открыть и проверить? Мой текущий билд с Update8 возвращает ошибку при попытке открыть Table Browser из средств разработки. Но у меня сильно промежуточный билд... Поэтому ошибка ничего не значит. Цитата:
system administrators can only access the table browser in read-only mode on runtime environments
В коде, как и раньше, стоит: X++: allowEdit = isSystemAdministrator() && isDeveloper(); |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
06.07.2017, 12:07 | #12 |
Участник
|
На моей практике этот финт приходилось делать раз 30.
Каждый раз данные грохали в настроечных табличках. К счастью там не было опасных delete action. В самом плохом случае с момента удаления прошло дней 5. В общем-то восстанавливать надо было только удаленные записи и все. Крайне редко - перепроводить документы за период. Конечно это очень частный случай от всех возможных поломок, но почему-то именно он реализуется с завидной регулярностью. Не знаю почему так. |
|
06.07.2017, 12:12 | #13 |
Участник
|
грохнутые настроечные таблички != система после аварии.
Logger, прекратите демагогию. Понятно, что "вы имели в виду". но побочные эффекты вашего предложения хуже болезни в общем случае. и сформулировано логически отвратно. бу-э-э-э... не надо продолжать эту тему в этой ветке. |
|
06.07.2017, 12:16 | #14 |
Участник
|
Не знаю.
В голову не приходит ничего, кроме "решение внутренних задач разработчиков". |
|
06.07.2017, 12:29 | #15 |
Участник
|
Цитата:
Цитата:
this is in reaction to live incidents caused by human error when system administrators inadvertently edited or removed live system data.
|
|
06.07.2017, 12:38 | #17 |
Участник
|
Цитата:
в SQL Server к примеру можно использовать change tracking |
|
|
За это сообщение автора поблагодарили: Logger (3). |
06.07.2017, 12:40 | #18 |
Участник
|
давайте про восстановление - в отдельную ветку.
Цитата:
а смысл то в чем? чтобы ваши админы не правили ничего? бред, жеж. скорее смысл, чтобы саппорт не обязан был разгребать инцидент. вот это и есть "решение внутренних задач разработчиков". но по факту получается: убрать из системы стандартные инструменты, которые вынуждают саппорт разгребать. ровно в том же ключе, что и code seal. ровно в том же ключе, что и запретить on-premise. |
|
06.07.2017, 12:42 | #19 |
Участник
|
возвращая к теме - вообще подобный запрет имел бы смысл если бы была возможность накатывать изменения онлайн. Кстати обещают ли такое или это никому не нужно?
а так получается - нашли ошибку, единственный шанс это поправить был - поправить данные сейчас как я понял предлагается ждать 3 часа пока установится фикс |
|
06.07.2017, 12:48 | #20 |
Banned
|
Цитата:
Или попробуем удалить поставщика, если его уже единожды попытались внести в строку журнала ГК, т.е. если сформировался dynamic dimension. Опыт общения с DSE был, когда попросили поменять статус у двух командировочных отчетов. 2 месяца на коленях перед ними ползали. |
|
Теги |
#синдромвахтера, change tracking |
|
|