<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
Сравнение-объединение в 8-ке переносит реквизиты вместе с их внутренними идентификаторами.
Скорее всего объекты, из новой конфигурации поставщика, переносили с помощью Ctrl+C — Ctrl-V
1. Справка — О программе — Версия конфигурации
2. Конфигурация — Поддержка — Настройка поддержки — Версия
Эти две версии совпадали до ваших действий?
Пробовали играться с настройкой «Установить соответствие объектов» при сравнении/объединении с конфигурацией поставщика? Может это будет правильным решением вашей проблемы?
(1)
Откуда информация? 1с говорит об обратном.
Если например в хранилище добавить новый объект и потом сравнить/объединить цф с рабочей, то новый объект будет с новым, отличающимся от хранилища, идентификатором. Так же новым будет имя таблицы в СУБД, но не об этом речь.
Соответственно следующее сравнение цф будет более долгим, т.к. по ГУИДу объект не будет найден и будет произведен поиск по ИМЕНИ для сопоставления.
Как-то так.
А вот при полной замене цф все идентификаторы будут заменены на те, что в файле цф.
В старой базе объект называется так-же. Через типовую 1С-овскую загрузку/выгрузку в xml просто переносим из старой базы все данные.
Сейчас провёл эксперимент:
Типовая БП КОРП. Создал копированием второй справочник «Банки». Перевёл все ссылки/подписки на него. Первоначальный «Банки» снял с поддержки и удалил. Убедился что сравнение объединение мой «Банки» с типовым «Банки» не соотносит.
Снял базу с поддержки. Сделал «Сравнить/объединить» с предварительно выгруженным Cf-ником типовой. Поставил на поддержку. У «Банки» появился «замок». Данные из него не пропали и теперь сравнение с типовой через поддержку не видит в нём различий.
Поэтому поддерживаю (5) комментарий — на практике попробовал: правильный способ описан, лучше чем в статье!
(5)
1.Снять с поддержки и «сравнить объединить..»с постановкой на поддержку с текущим .cf поставщика (который можно тут же и выгрузить), вернет всем объектам родные уиды. т.к. сравнение идет по именам объектов. а все дописи соттветственно в лице реквизитов новых останутся.
2. сравнить с измененной конфой на предмет изменений модулей и форм…радоваться..
Более того, этот способ можно применять для целенаправленного снятия с поддержки конфигураций подключенных к хранилищу при сохранении возможности обновляться на следующие релизы.
Если баз для тестирования и разработки много, а конфигурация большая, например ERP , то за счет исключения конфигурации поставщика из каждой базы получается значительная экономия дискового пространства, особенно если базы для разработки не являются копиями типовых конфигураций, а являются демо-базами с небольшим объемом данных. Также это полезно для ускорения синхронизации хранилища с Git-репозиторием и уменьшения объема самого репозитория.
Перед обновлением на новый релиз достаточно поставить на поддержку одну из баз через сравнение-объединение с CF-файлом текущего релиза. После чего можно переходить на новый релиз через механизм поддержки.
Есть только одна тонкость. Не все объекты могут быть сразу поставлены на поддержку автоматически после объединения с CF-файлом текущего релиза. Для того чтобы поставить на поддержку все типовые объекты нужно зайти в настройку поддержки, выбрать для корня конфигурации правило «Редактируется с сохранением поддержки» и поставить флаг рекурсивной установки этого правила для подчиненных объектов.
Также этот способ имеет смысл применять только если в компании принят стандарт наименования добавленных в конфигурацию новых объектов. Например их префиксация или постфиксация. Ведь при снятии с поддержки теряется визуальная идентификация типовых объектов.
(5)
В первый раз столкнулась с такой ситуацией, сравнение измененной и типовой резало глаз, список изменений уходил в даль.
В помощь не нагуглила ничего ценного.
Как я вышла из ситуации описала в статье — если есть лучший способ — прекрасно, в другой раз конечно его использую.
Спасибо.
(3)
Из личного опыта.
Создайте базу с одним справочником, выгрузите ЦФ
Создайте еще одну базу с одним справочником (лучше с другим именем, чем в первой), сравните и объедините в нее ЦФ от первой базы
Разберите конфигурации на файлы и посмотрите там ГУИДы справочников.
Не путайте с наименованием таблиц и полей.
(8) Спасибо, закрыли пробел для будущих поколений…)… сделал в помощь..
Быстрый способ сохранить свое бесценное время… Первопричины: При сравнении с базой поставщика, через Поддержка-Настройка поддержки, дает значительный разбег конфигураций — примерно 40(100500)% измененных объектов + 20(100500)% удаленных и новых, все объекты базы «разрешены изменения» у многих «снят с поддержки».
Рецепты:
Основной:
1.Снять с поддержки и «сравнить объединить..»с постановкой на поддержку…» с текущим .cf поставщика (который можно тут же и выгрузить. Важно: при расхождении номеров версий конфигураций основной и поставщика, конечно нужно найти/использовать релиз поставщика, именно с номером основной конфигурации), вернет всем объектам родные уиды и замки. т.к. сравнение идет по именам объектов. а все дописи соответственно в лице реквизитов новых останутся.
2. сравнить с измененной конфигурацией(которую можно тут же и выгрузить) на предмет изменений модулей и форм, привести в соответствие, необходимые изменения…радоваться..
(10)
но насчет «сравнение идет по именам объектов» часто в версиях имена и объектов и общих модулей и форм меняются.
(11)так мы же текущую конф.основную ставим на поддержку на текущую.поставщика. где ж там будут такие изыски…а не сразу летим на самый крайний..)..рекомендую именно с этого начать..), т.е. релизы ставим номер в номер..
(9) Есть на итс вот такая древняя .
В ней упоминание про древние релизы платформы. Но по существу скорости сравнения конфигураций воз и ныне там. Поэтому я склонен верить статье.
Действительно при сравнении конф и добавлении нового справочника uuid, которые мы видим в выгрузках конф в xml вроде как те же самые.
Это мы видим глазами. И то что видим — называем личным опытом. Вроде как не подкопаться.
Однако я так же вижу, что при групповой разработке, если рабочая (продакшн) база не подключена к хранилищу (обновляется ч/з сравнение/объединение), то после первого же добавленного нового объекта в хранилище сравнение начинает подтупливать. Чем больше новых объектов было добавлено после создания хранилища — тем больше тормозит сравнение. Из 10-20 сек сравнение может превратиться в 10-30 минут.
Есть еще интересная особенность… Если развернуть в тестовую базу бэкап обновленной рабочей базы и подключить ее к хранилищу (дефакто конфигурации будут в такой момент одинаковые), то конфигурация бэкапа заменится за конфигурацию хранилища. При последующем обновлении пройдет реструктуризация половины базы несмотря на фактическое отсутствие изменений. Никогда не расследовал что именно реструктуризируется, но предположу, что это именно новые объекты (созданные в процессе жизни хранилища). И еще замечу, что если рабочая база подключена к хранилищу разработки и из него обновляется через получение изменений, то такого эффекта нет.
Это тоже опыт. И даже не личный, а коллективный.
Возможно он не противоречит тому что мы видим в xml, а всего лишь говорит о том, что мы видим не все.
(3)
Проверил:
Сделал базу Рабочая с одним справочником
Скопировал .1сд файл Рабочей в две базы Хран1 и Хран2
Из Хран1 создал хранилище конфигурации
Подключил Хран2 к хранилищу.
В Хран2 добавил новый справочник. Закоммител изменения.
Получил изменения в Хран1
Выгрузил ЦФ из Хран1
СравнилИОбъеденил ЦФ с Рабочей базой
Все базы разобрал — ГУИДы везде одинаковые
(15)
Зачем гадать?
Ответил в (16)
(17)
Ранее я написал:
Не совсем подробно описал: это я сверял самый первый новый объект, созданный в хранилище, с рабочей базой. В рабочую добавляем через «Сравнить/объединить». Гуид оказался одинаковым. Так что я подтверждаю, что они равны…
Но, это не отменяет того факта, что при подключении к хранилищу свежей базы происходит массовая реструктуризация (хотя конфигурации равны). Я не знаю чем это объяснить, т.к. если нет изменений, то зачем реструктуризировать данные? Добавилась какая-то служебная информация для конфигурации (чтобы функционировать в хранилище), но данные то тут при чём? При обновлении и то меньше реструктуризируется, чем при подключении к хранилищу!
Плюс в ИТС в двух местах прямо написано, что при сравнить/объединить гуиды не должны быть равны, а в одном косвенно указывают на то, что должны копироваться.