Изменения в Table Browser в последнем Platform Update 8

[kashperuk]

Видели, что теперь администраторы не смогут данные править через обозреватель таблиц на 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.

[Logger]

О! Теперь я знаю какая будет самая первая модификация в системе !
Открыть на редактирвание / скопипастить SysTableBrowser

[mazzy]

Цитата:

Сообщение от Logger

Открыть на редактирвание / скопипастить SysTableBrowser

ну... там теперь сложнее несколько. на ровном месте.

но я абсолютно не соменваюсь, что народ сделает.

[fed]

Цитата:

Сообщение от mazzy

ну... там теперь сложнее несколько. на ровном месте.

но я абсолютно не соменваюсь, что народ сделает.

On-Premise рулит !
Нету у них в уголовке методов против T-SQL

[mazzy]

Вставай на нано-лыжи
Садись за нано-книги
На-на-на позитиве....
https://promodj.com/vengerov-fedorof...dio_Edit_Remix

А чего ты обсудить хочешь?
Это общая тенденция в МС - "куда они от нас денутся?"
Денутся, конечно. На крайняк сделают свои браузеры. Сделали же.

А запретили наверняка потому что где-то какие-то тесты не проходят
и у разработчиков МС не хватает ресурсов, чтобы сделать по-человечески.
вот и делают очередной workaround.

[mazzy]

Цитата:

Table browser is now in read-only mode

Цитата:

Сообщение от kashperuk

Видели, что теперь администраторы не смогут данные править через обозреватель таблиц на live environments?

И еще. А давай читать внимательно.

Здесь не сказано "read-only mode only"
Может, оно открывает в read-only, а потом можно переключить в нормальный режим?

Ваня, можешь открыть и проверить? Мой текущий билд с Update8 возвращает ошибку при попытке открыть Table Browser из средств разработки. Но у меня сильно промежуточный билд... Поэтому ошибка ничего не значит.

[kashperuk]

Цитата:

Сообщение от 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

Не знаю, как именно они это сделали, но явно не через application code. Во всяком случае за минуту поиска я не нашел.

В коде, как и раньше, стоит:

allowEdit   = isSystemAdministrator() && isDeveloper();

[mazzy]

Цитата:

Сообщение от kashperuk

Нет, иначе какой смысл.

Не знаю.
В голову не приходит ничего, кроме "решение внутренних задач разработчиков".

[kashperuk]

Цитата:

Сообщение от mazzy

Не знаю.
В голову не приходит ничего, кроме "решение внутренних задач разработчиков".

Ну, смысл они же описали там же, следующим предложением:

Цитата:

this is in reaction to live incidents caused by human error when system administrators inadvertently edited or removed live system data.

Админы заходили, правили что-то, система валилась, а потом наш саппорт это разгребал

[mazzy]

давайте про восстановление - в отдельную ветку.

Цитата:

Сообщение от kashperuk

Ну, смысл они же описали там же, следующим предложением:

Админы заходили, правили что-то, система валилась, а потом наш саппорт это разгребал

они описали не смысл, а реакцию на инцидент.

а смысл то в чем?
чтобы ваши админы не правили ничего? бред, жеж.

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

но по факту получается:
убрать из системы стандартные инструменты, которые вынуждают саппорт разгребать.
ровно в том же ключе, что и code seal.
ровно в том же ключе, что и запретить on-premise.

[Vadik]

Цитата:

Сообщение от kashperuk

Админы заходили, правили что-то, система валилась, а потом наш саппорт это разгребал

А у нас клиент настроил database log на все-все-все, продуктив + sandbox за две недели превысили 1 TB квоту и все встало. Отключим database log ?

[Logger]

Цитата:

Сообщение от kashperuk

Видели, что теперь администраторы не смогут данные править через обозреватель таблиц на live environments?

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

Правильнее было бы предусмотреть удобный механизм отката изменений.
Например в оракл есть удобный механизм флешбека.
Просто пишешь запрос

SELECT * FROM SCHEMA.TABLENAME /* AS OF TIMESTAMP TO_TIMESTAMP('2017-06-30 12:50:00', 'YYYY-MM-DD HH24:MI:SS') */ A
WHERE 
...

и видишь данные на любой момент времени.

Если к тебе прибежал испуганный программист/админ/юзер - шеф все пропало, гипс снимают, клиент уезжает "Я нечаянно удалил тучу данных!"
то просто берешь и пишешь

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(*) на разную дату время чтобы поймать лучше момент времени с которого ндао взять удаленные впоследствии данные.

И затем восстанавливаешь их

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 штатно такое сделать ? Вроде до сих пор нельзя.

[mazzy]

Цитата:

Сообщение от Logger

Как бы в SQL Server штатно такое сделать ? Вроде до сих пор нельзя.

И не надо.
Точно по тем же причинам, почему не надо делать удаление и редактирование проведенных документов - в многопользовательской системе на основании отредактированных данных могут создать новые документы/данные.
Откат/удаление/редактирование проведенных может нарушить целостность.

Если речь идет о монопольном редактировании, то делать опасные изменения после создания бэкапа/снапшота базы,

[Logger]

Не надо ?
Вам не нужен инструмент, позволяющий за 10 минут восстановить систему после аварии ?
Подъем бекапа может занять часы или сутки.

LOL

[mazzy]

Цитата:

Сообщение от Logger

Вам не нужен инструмент, позволяющий за 10 минут восстановить систему после аварии ?
LOL

а он восстанавливает систему?

LOL

[Logger]

Цитата:

Сообщение от mazzy

а он восстанавливает систему?

На моей практике этот финт приходилось делать раз 30.
Каждый раз данные грохали в настроечных табличках. К счастью там не было опасных delete action. В самом плохом случае с момента удаления прошло дней 5.
В общем-то восстанавливать надо было только удаленные записи и все. Крайне редко - перепроводить документы за период.
Конечно это очень частный случай от всех возможных поломок, но почему-то именно он реализуется с завидной регулярностью. Не знаю почему так.

[mazzy]

Цитата:

Сообщение от Logger

позволяющий за 10 минут восстановить систему после аварии

Цитата:

Сообщение от Logger

грохали в настроечных табличках.

грохнутые настроечные таблички != система после аварии.
Logger, прекратите демагогию.

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

не надо продолжать эту тему в этой ветке.

[trud]

Цитата:

Сообщение от Logger

Не надо ?
Вам не нужен инструмент, позволяющий за 10 минут восстановить систему после аварии ?
Подъем бекапа может занять часы или сутки.

вообще инструментом восстановления после аварии является документ- план восстановления(с указанием проблем и порядка действия когда они возникнут) и периодическое тестирование этого плана
в SQL Server к примеру можно использовать change tracking

[EVGL]

Цитата:

Сообщение от kashperuk

Видели, что теперь администраторы не смогут данные править через обозреватель таблиц на live environments?

Fed был прав. Когда казалось, что хуже уже быть не может, эти су...и придумывают что-нибудь еще.

[trud]

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