Скорее всего потому что вы вносили свои изменения в код движка и у вас идет попытка работы с URFA вне секции init, а в секции write_body() или типа того. Измените код чтоб работа с URFA шла в нужном месте.Nokis писал(а):Nokis писал(а):Подскажите пожалуйста, почему может возникать такая ошибка при входе в личный кабинет ?
может быть, что это связано с тем, что данные передаются по http протоколу ?
Первые впечатления от 008
LostSoul- писал(а):Скорее всего потому что вы вносили свои изменения в код движка и у вас идет попытка работы с URFA вне секции init, а в секции write_body() или типа того. Измените код чтоб работа с URFA шла в нужном месте.Nokis писал(а):Nokis писал(а):Подскажите пожалуйста, почему может возникать такая ошибка при входе в личный кабинет ?
может быть, что это связано с тем, что данные передаются по http протоколу ?
Пожалуйста, скажите кто-нибудь, как сделать чтоб все услуги формировало в один счет, а не в несколько....
Проблему с зависанием биллинга пока не решили, но Алексей Б. из Нетап, активно занимается проблемой и надеюсь решение её уже близко.
Спасибо тех. поддержке за активное участие в поиске "плавующего" бага и отдельное спасибо Алексею.
P.S. модули так кстати никто и не взялся написать для 008 ;(, грустно потому, что приходится держать и самописный ЛК (qiwi/webmoney/nod32/drweb) и нетаповский.
Спасибо тех. поддержке за активное участие в поиске "плавующего" бага и отдельное спасибо Алексею.
P.S. модули так кстати никто и не взялся написать для 008 ;(, грустно потому, что приходится держать и самописный ЛК (qiwi/webmoney/nod32/drweb) и нетаповский.
В "Добровольной блокировке" не удается изменить уже выставленный период блокировки на более ранний.
Например: пользователь запланировал приостановить на месяц с 15-го июня, но вдруг решает с 1-го июня. Даже при включенной возможности самостоятельного снятия блокировки пользователем-нажимает кнопку "Снять"=>Блокировка снимется,но другую дату он выставить не сможет до 15 июня.
Подскажите, пожалуйста, каким образом можно это решить.
Например: пользователь запланировал приостановить на месяц с 15-го июня, но вдруг решает с 1-го июня. Даже при включенной возможности самостоятельного снятия блокировки пользователем-нажимает кнопку "Снять"=>Блокировка снимется,но другую дату он выставить не сможет до 15 июня.
Подскажите, пожалуйста, каким образом можно это решить.
-
littlesavage
- Сообщения: 120
- Зарегистрирован: Вс ноя 22, 2009 02:41
- Откуда: Чебоксары
Небольшой ахтунг с версией 007.
Если попробовать подключиться админкой от 008 к utm'у версии 007upd 10, сервер UTM'а вывалится в кору с SSL type requested: UNKNOWN(4).
Будьте осторожны
PS: А, кхм, Magnum72 описывал уже
UP: Чтобы повесить ядро таким способом нужны валидные логин-пароль, но абонентского логина-пароля вполне достаточно.
Если попробовать подключиться админкой от 008 к utm'у версии 007upd 10, сервер UTM'а вывалится в кору с SSL type requested: UNKNOWN(4).
Будьте осторожны
PS: А, кхм, Magnum72 описывал уже
UP: Чтобы повесить ядро таким способом нужны валидные логин-пароль, но абонентского логина-пароля вполне достаточно.
Таксс...подскажите плз люди добрые
Стоит Version:5.2.1-004-bsd6
Пытаюсь обновитьяс до версии 5.2.1-005.
Получилось плохо.
http://mob.tih.ru/tmp/main.log
http://mob.tih.ru/tmp/debug.log
http://mob.tih.ru/tmp/verificator.log
Подскажите в какую сторону капать?
была тема насчет basic_account - viewtopic.php?t=6443
ну таких в БД пользователей нет.
select * from users where basic_account="0";
Empty set (0.00 sec)
Стоит Version:5.2.1-004-bsd6
Пытаюсь обновитьяс до версии 5.2.1-005.
Получилось плохо.
http://mob.tih.ru/tmp/main.log
http://mob.tih.ru/tmp/debug.log
http://mob.tih.ru/tmp/verificator.log
Подскажите в какую сторону капать?
была тема насчет basic_account - viewtopic.php?t=6443
ну таких в БД пользователей нет.
select * from users where basic_account="0";
Empty set (0.00 sec)
Вы апдейт базы сделать не забыли случаем ?Нафаня писал(а):Таксс...подскажите плз люди добрые
Стоит Version:5.2.1-004-bsd6
Пытаюсь обновитьяс до версии 5.2.1-005.
Получилось плохо.
http://mob.tih.ru/tmp/main.log
http://mob.tih.ru/tmp/debug.log
http://mob.tih.ru/tmp/verificator.log
Подскажите в какую сторону капать?
была тема насчет basic_account - viewtopic.php?t=6443
ну таких в БД пользователей нет.
select * from users where basic_account="0";
Empty set (0.00 sec)
Вы структуру базы обновляли во врмя обновления? Так как при обновлении затрагиваются эти таблицы то скрипт будет работать несколько часов, если у вас обновление базы пролетело за пару секунд, то скорее всего SQL не отработал.Нафаня писал(а):У меня в этой версии 004 нет архивации и она ни когда не деаллась. там 50млн записей. Может перед апдейтом что то нужно сделать с таблицами транзакшн и транзакшн олл ?
Выполняй апдейт базы построчно, бери каждую строку в скрипте и выполняй, таблицы транзакций оставь на последок.Нафаня писал(а):да за несколько секунд. ( повисел и все ну как бы ошибки не выскочили.сейчас дебаг включу. проверю. а как можно обойти это? ведь там данных куча. мускул скорее всего падаетпервые подозрения на это.
сложный вариант но более быстрый с переименованием таблиц:
переименуй таблицы транзакций, создай новые, обнови структуру, влей в них данные за текущий месяц из старых, на старых потом запустишь механизм архивирования.
ЗЫ в принципе можешь пока преименовать таблицы транзакций, создать новый поставить у них автоинкремент выше чем в старых, запустишь биллинг у тя останется 3 дня чтобы перенести в них данные за этот месяц до закрытия периода, а вообще апдейт лучше делать в начале периода, пока текущих данных мало.
Так дошди руки до построчного обновления.
mysql> ALTER TABLE pre_invoice ADD COLUMN id int(11) NOT NULL auto_increment PRIMARY KEY;
ERROR 1060 (42S21): Duplicate column name 'id'
mysql> ALTER TABLE pre_invoice ADD COLUMN slink_id int default '0';
ERROR 1060 (42S21): Duplicate column name 'slink_id'
mysql> ALTER TABLE pre_invoice ADD COLUMN discount_period_id int default '0';
ERROR 1060 (42S21): Duplicate column name 'discount_period_id'
mysql> ALTER TABLE pre_invoice ADD COLUMN tclass int default '0';
ERROR 1060 (42S21): Duplicate column name 'tclass'
mysql> ALTER TABLE pre_invoice ADD COLUMN base_cost REAL default '0';
ERROR 1060 (42S21): Duplicate column name 'base_cost'
mysql> ALTER TABLE pre_invoice ADD COLUMN qnt REAL default '0';
ERROR 1060 (42S21): Duplicate column name 'qnt'
mysql> ALTER TABLE pre_invoice ADD COLUMN sum_cost REAL default '0';
ERROR 1060 (42S21): Duplicate column name 'sum_cost'
mysql> ALTER TABLE pre_invoice ADD COLUMN sum_cost_with_tax REAL default '0';
ERROR 1060 (42S21): Duplicate column name 'sum_cost_with_tax'
mysql> ALTER TABLE pre_invoice DROP COLUMN zzzzz;
ERROR 1091 (42000): Can't DROP 'zzzzz'; check that column/key exists
ну итд....
mysql> ALTER TABLE pre_invoice ADD COLUMN id int(11) NOT NULL auto_increment PRIMARY KEY;
ERROR 1060 (42S21): Duplicate column name 'id'
mysql> ALTER TABLE pre_invoice ADD COLUMN slink_id int default '0';
ERROR 1060 (42S21): Duplicate column name 'slink_id'
mysql> ALTER TABLE pre_invoice ADD COLUMN discount_period_id int default '0';
ERROR 1060 (42S21): Duplicate column name 'discount_period_id'
mysql> ALTER TABLE pre_invoice ADD COLUMN tclass int default '0';
ERROR 1060 (42S21): Duplicate column name 'tclass'
mysql> ALTER TABLE pre_invoice ADD COLUMN base_cost REAL default '0';
ERROR 1060 (42S21): Duplicate column name 'base_cost'
mysql> ALTER TABLE pre_invoice ADD COLUMN qnt REAL default '0';
ERROR 1060 (42S21): Duplicate column name 'qnt'
mysql> ALTER TABLE pre_invoice ADD COLUMN sum_cost REAL default '0';
ERROR 1060 (42S21): Duplicate column name 'sum_cost'
mysql> ALTER TABLE pre_invoice ADD COLUMN sum_cost_with_tax REAL default '0';
ERROR 1060 (42S21): Duplicate column name 'sum_cost_with_tax'
mysql> ALTER TABLE pre_invoice DROP COLUMN zzzzz;
ERROR 1091 (42000): Can't DROP 'zzzzz'; check that column/key exists
ну итд....