[ОТВЕТИТЬ]
24.02.2016 16:13
УКМ_эксплуатант_2
 
УКМ4 версии 67СП3
В бд стандартного экпорта 4 есть таблицы shift_result. Заполнятся нормально. Как только запускается "что-то" в 1С-е - в этой таблице становится пусто.
По моим данным кроме 1С-ки этой БД больше никто не пользуется. А одинэсники пяткой в грудь стучат: ну ведь русским по белому написано только ЧИТАТЬ или ОБНОВЛЯТЬ.
Вопрос: как включить запись всех запросов к опрдленной БД? Медленные протоколировать умею. Хочу все.
24.02.2016 16:25
Micle
 
включи репликацию. в файл будут попадать все запросы связанные с обновлением данных. запросы на чтение попадать не будут. насколько я понимаю, они и не нужны.
24.02.2016 17:12
УКМ_эксплуатант_2
 
Включил логирование всех запросов.
log=/var/log/mysql/mysql.log # Лог всех SQL-запросов
Нашел запрос на делит
Осталось определить кто его посылает.
Ковыряю инет на анализатор лога..
25.02.2016 10:31
XsevenBeta
 
Можно прямо в онлайне включать и выключать:
SET GLOBAL general_log = 'ON';
SET GLOBAL general_log = 'OFF';
SET GLOBAL general_log_file= 'd:/temp/mysql-query.log'
26.02.2016 12:31
УКМ_эксплуатант_2
 
Наковырял следующее:
поставил тригеры на BEFORE DELETE, BEFORE UPDATE, BEFORE INSERT
с содержанием:
SQL код:
CREATE DEFINER 'ПОЛЬЗВАТЕЛЬ'@'%' TRIGGER `shift_before_ins_trBEFORE INSERT ON `shift`
  FOR 
EACH ROW
BEGIN
insert into 
`tbl_log_delete` (u_ser,dt,tipvalues (USER(),NOW(),"ins");
END
(tip для каждого события свой)
ну и логирование запросов включил.
В таблице tbl_log_delete видно что пользователь 1С производит DELETE
Но вот лог запросов смутил:
Код:
160226 11:55:18	    251 Connect     ПОЛЬЗОВАТЕЛЬ 1С@ИМЯ_МАШИНЫ_С_1С on export_no_sh
		    251 Query       SET NAMES utf8
		    251 Query       SET character_set_results = NULL
		    251 Query       SET SQL_AUTO_IS_NULL = 0
		    251 Query       set @@sql_select_limit=DEFAULT
		    251 Query       SELECT
CAST(SUM(T1.
бла-бла-бла
T1.`ext_status`
FROM shift T1 
WHERE (T1.`ext_status` = 0)
		    251 Query       SELECT
T1.store,
бла-бла-бла
ORDER BY T1.`cash_id`, T1.id
		    251 Query       SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE
		    251 Query       SET AUTOCOMMIT=0
		    251 Query       DELETE FROM shift 
WHERE shift.`cash_id` = 15012001 AND shift.id = 1135
160226 11:55:19	    251 Query       DELETE FROM shift 
WHERE shift.`cash_id` = 15012001 AND shift.id = 1135
		    251 Query       INSERT INTO shift  (store,`cash_number`,`cash_id`,id,number,login,date,sale,return,cancel,`cancel_return`,`close_login`,`close_date`,`ext_status`) VALUES
('025','1','15012001','1135','1222','1474','2016-02-23 07:58:45','330703038.68','14820900.83','9753418.94','160810.14','1474','2016-02-23 23:08:19','1')
		    251 Query       ROLLBACK
		    251 Query       SET AUTOCOMMIT=1
		    251 Query       SELECT
бла-бла-бла
Видно, что 1С сначала делитит запись, потом вставляет, НО ПОТОМ!!! делает откат транзакции!

Вопрос: сие является признаком того, что "виноват" в "пустой таблице" одинэс? Ведь сам смотрел исходники на чистом русском: нет слова УДАЛИТЬ!
Ну и как это можно попробовать исправить?
З.Ы. И че смотрел смотрел исходники - там можно было написать все что угодноо: я ж по 1С читать не умею

З.З.Ы. Попытался "завернуть" лог в спойлер - запросил какую-то опцию. Что это?
26.02.2016 12:40
Mtirt
 
Так запросы в 1С обычным текстом, обычно.
26.02.2016 12:53
УКМ_эксплуатант_2
 
Цитата:
Mtirt Так запросы в 1С обычным текстом, обычно.
эээ, а подробнее?

В результате экспериментов выяснил следующее:
закопипастил эти запросы (от connect до set autocommit=1)
в EMS MySQL Manager
и на выполнение запустил по одному.
Все до инсерта - сработало.
А вот инсерт - нет Дает ошибку.
Добавил имя таблицы перед полем return - заработало!

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

З.Ы. Позвонил одинэсникам - запросами не пользуются. Создают объект (в разговоре упоминалось ODBC) и работают с таблицей как с объектом ( помню что при заполнении таблицы items БД стандартного импорта 4 им пришлось явно указывать ВСЕ поля, а я в запросе - только те, которые нужны). ВНИМАНИЕ: сии слова я пишу без понимания их Примерно догадываюсь, но не уверен....
26.02.2016 15:27
vdm
 
Таблицы этого конвертера наверняка MyISAM, т.е. commit/rollback им побоку, изменения фиксируются сразу. Возможно где-то проскакивает DELETE без условий.

Ошибка на имени поля return - а в обратные апострофы `return` заключить не помогает?
26.02.2016 15:33
Mtirt
 
У меня нескромный вопрос: а зачем 1С-никам что-то делать в базе УКМ4?
Можно их отправить лесом?
29.02.2016 08:33
УКМ_эксплуатант_2
 
Дык это-ж таблицы конвертера обмена!
Все по правилам: поля с именем начинающиеся с "ext_" - для внешних программ и можно делать с ними что угодно.
По этому полю 1С-ка ориентируется: обработанна запись или нет (при появлении данных там NULL, после того как 1С обработала запись - 1. Почему так - не спрашивайте, НЕЗНАЮ. Дал одинэсникам описание конвертера - получил такие проблемы )
Надо было давать Стандартный 2DBF. Хотя, не прокатило-бы - самая актуальная информация - в Стандартном экспорте 4 (ну не актуальная - полная)....
29.02.2016 08:36
УКМ_эксплуатант_2
 
Цитата:
vdm Таблицы этого конвертера наверняка MyISAM, т.е. commit/rollback им побоку, изменения фиксируются сразу. Возможно где-то проскакивает DELETE без условий.

Ошибка на имени поля return - а в обратные апострофы `return` заключить не помогает?
Как уже писал - 1С использует какой-то иной механизм работы с БД, а не прямые запросы (ну не доктор я в этом!!).
Провел некоторые эксперименты вместе одинэсниками - выяснили, что при изменении поля в таблице от 1С поступает сначала запрос на удаление записи, а потом на вставку. Вместо одного update.
И эти запросы (delete&insert) формируются автоматически...
Буду делать отдельную процедуру на поле этой таблицы...

В принципе - тему можно закрыть, так как продолжение темы не имеет никакого отношения к протоколированию...
29.02.2016 08:44
student
 
Цитата:
УКМ_эксплуатант_2 сначала запрос на удаление записи, а потом на вставку. Вместо одного update.
такое построение часто бывает правильным на больших объемах индексированных данных - скорость обработки выше ...
29.02.2016 09:13
Micle
 
Что если перевести базу на движок с поддержкой транзакций? Как я понимаю, проблема в этом...
29.02.2016 09:31
student
 
Цитата:
Micle Что если перевести базу на движок с поддержкой транзакций?
а разве мускул укм 4-го их не поддерживает ? (я просто реально не в курсе - с ним практически дела не имел...)
я проверял для себя на ms sql (поддержка транзакций в нем есть :)) - удаление и вставка быстрее одного апдейта на большом объеме индексированных данных
29.02.2016 10:43
Micle
 
Мускул поддерживает транзакции не на всех "видах" таблиц. Что будет быстрее, что медленнее утверждать не берусь. НО как понимаю, проблема с удалением вылезла именно из за отсутствия поддержки транзакций. При неудачно инсерте программа делает откат транзакции, чтобы восстановить удалённые данные. Скорее всего в Вашем случае используется MyISAM движок, в то время как для поддержки транзакций нужен InnoDB
02.03.2016 09:30
УКМ_эксплуатант_2
 
Базенка для Стандартного экспорта как раз не поддерживает транзакции - MyISAM.
Переводить на транзакционную (InnoBD) - ну на.
Да и проблема в совпадении имен полей с ключевыми словами плюс то, что 1С (скорее всего не 1С, а ODBC) не умеет умеет их экранировать апострофами.
02.03.2016 10:43
Micle
 
я кстати, не вижу никаких проблем чтобы из 1с обращаться в базу на прямую в обход ODBC... во всяком случае MsSQL в лёгкую у меня программисты данные читают/пишут
Опции темы


Часовой пояс GMT +3, время: 22:51.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.