Аустановка админской блокировки скриптом

[mrDefault]

Доброго времени суток!

Есть задача заблокировать часть абонентов админской блокировкой (пересчитывать АП и трафик)

покопался в базе увидел что за блокировку отвечает код блокировки в is_blocked табличка accounts, на тестовом сервере выставил одному абоненту такой же код блокировки, после рестарта ядра, вроде он заблокировался, при смене РП деньги не списались, вроде все как надо. Но заметил что теперь если блокировать из админки, то код этой блокировки увелиечлся. посмотрел логи увидел что при блокировке идет изменения не только таблицы accounts . Короче говоря, собственно вопрос, есть у кого готовые, корректно работающие запросы для выставления блокировок, если есть поделитесь пожалуйста, буду признателен . Нужно срочно а времени нет писать свои запросы и тестировать как на них отреагирует биллинг и не будет ли потом косяков

[Pulse]

только через urfa функции!

[NShut]

можно ночью utm_core stop
/script_go
utm_core start

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

[mikkey finn]

мне пришлось, чтоб ядро успевало за urfa-php, вставить задержки суммарно на 10сек. Но по мне - так лучше пусть скрипт будет час вносить резервированные адреса по списку, чем кто-то руками наделает ошибок за 8 часов. И уж тем более лучше так, чем напрямую в БД.

[mrDefault]

можно ночью utm_core stop
/script_go
utm_core start

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

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

мне пришлось, чтоб ядро успевало за urfa-php, вставить задержки суммарно на 10сек. Но по мне - так лучше пусть скрипт будет час вносить резервированные адреса по списку, чем кто-то руками наделает ошибок за 8 часов. И уж тем более лучше так, чем напрямую в БД.

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

только через urfa функции!

Спасибо, что-то у меня такое подозрение было