BiTel

BGCRM v 3.0 build 1057 from 20.09.2015 11:23:01
при запуске обновления пытается обновиться на -
BGCRM v 3.0 build 1106 from 18.01.2016 23:58:06

./install.sh update =>

обращения к базе через некотрое количество вызывают ошибку в консоль-
Can't create more than max_prepared_stmt_count statements (current value: 16382) => CALL drop_column_if_exists('callboard_task', 'date')

обновление проходит криво, хотя в log_update - всё прекрасно- статус всех sql запросов ok
другие sql запросы в системе работают нормально(тут же крутится bgbilling и если откатить bgcrm - там тоже всё нормально).

зачем так странно обновлять базу?!
и как её вообще обновить?

ps кстати вызов списка процессов в перезапущеном црме вызывает ошибку "com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Unknown column 'pm_state.in_last_id' in 'on clause'"
и между прочим сочетание букв - pm_state.in_last_id вообще не встречается в последнем обновлении, т.е. даже если оно проёдёт с успехом - ошибка будет.

ладно, эту проблему(Can't create more than max_prepared_stmt_count statements) с я могу обойти, но

проблему "com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Unknown column 'pm_state.in_last_id' in 'on clause'"
я победить не смогу - после обновления система не работает..

При команде старта в логе какая ошибка?

в логе апдейта нет ошибок:

Update starting..
Update from ftp://ftp.bgcrm.ru/pub/bgcrm
Version is 3.0
Set passive mode..
Changing dir to /pub/bgcrm/3.0
Checking update for 'update_lib'..
Found update for 'update_lib' build 50 updating to build 51
Checking update for 'update'..
Found update for 'update' build 1057 updating to build 1106
Downloading update_lib_3.0_51.zip OK!
Downloading update_3.0_1106.zip OK!
Start installing..
Executing call RemoveFile; param: lib/ext/ecj-3.7.jar
Result => true
Executing call RemoveFile; param: lib/ext/jsch-0.1.50.jar
Result => true
Execute calls => OK
File's copy finished...
File copy => OK
Module update_lib was successfull installed!
Please, restart BGCRM server.
Executing call ExecuteSQL; param: patch.sql
OK (3 ms.) => DROP PROCEDURE IF EXISTS drop_column_if_exists;

<!-- тут обойма SQL запросов чёрт, с ними, сейчас отрабатывают без ошибки max_prepared_stmt_count -->

OK (29 ms.) => ALTER TABLE param_tree_value MODIFY parent_id VARCHAR(50) NOT NULL
Executing database update...OK
Result => true
Executing call RemoveFile; param: action/pl_bgbilling.xml
Result => true
Executing call RemoveFile; param: action/pl_document.xml
Result => true
Executing call RemoveFile; param: action/pl_ufanet.xml
Result => true
Executing call RemoveFile; param: action/pl_report.xml
Result => true
Execute calls => OK
File's copy finished...
File copy => OK
Module update was successfull installed!
Please, restart BGCRM server.
REPLACED FILES:
lib/app/lib.jar

<!-- здесь список файлов. -->

этим лог обновления в консоль заканчивается.
как видите - ошибок нет.

в log_update_ .... всё тоже самое... какая такая ошибка? )) ошибки только после рестарта - не хватает столбцов в таблицах bd bgcrm

Самый старый билд нашел только 1093 обновился без проблем. Ждем разрабов

а вот кстаи, - при старте обновлённая система вываливет core_dump (hs_err_pidXXXX.log)
в логах от log4j. никаких проблем.
кстати, не знаю что это вывалилось, но bgcrm хоть и криво, но работает, на запросы клиентской стороны отвечает..

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

ну да, .. ждём..

тема закрыта )

проблема решилась ?

Опишите пожалуйста как решили.

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

ALTER TABLE address_house ADD KEY street_id(street_id)
ALTER TABLE `address_distribution` ADD INDEX `user_index` (`user_id`)
ALTER TABLE process_group ADD KEY group_id(group_id)
ALTER TABLE `address_distribution` ADD INDEX `user_index` (`user_id`)

Это нормально, у нас при каждом апдейте пытается все индексы, поля и т.п. заново добавить.

Неверно. В BGCRM обновление происходит через хранимые процедуры, которые сначала проверяют текущее состояние или лишь при необходимости применяют ALTER.

Интересно, как эта ошибка получилась:


Где там аж 16 тысячам PreparedStatement ов открыться..

это, вероятно, мой косяк (java скрипты где-нибудь не закрывают дескрипторы, после вылета по ошибке) и накапливаются. последнее обновление кстати даёт в sql блоке ошибки в консоль типа - таблица уже есть, не могу создать, но в лог этих сообщений не идёт. там всё ок.