<?php // Полная загрузка сервисных книжек, создан 2025-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='\
Как учитываются параметры виртуальных таблиц?
Как интерпретируется DATEPART?
Что делаете с типизацией?
А вообще уже было
3,5 года назад 🙂
За ссылку спасибо, действительно хороший вариант.
Что касается работы с виртуальными таблицами и DATEPART, то пока это не релизовано.
Типизация у меня реализована следующим образом: синтаксис заменяется на аналог из 1С если такой имеется и просто переводится на русский, если аналогичного типа в 1С нет.
(1) (2) Но в профайлере же мы увидим оптимизированные движком SQL запрос, а не преобразованный исходный? Или я ошибаюсь?
Безусловно в данной публикации рассмотрен и приведен нетривиальный метод преобразования запросов, довольно поучительный.
Но кажется в поиске «узких мест» не обязательно выбирать путь «подземный ход на чердак».
Если вы являетесь администратором данной базы данных 1С, то достаточно опросить пользователей и выявлять подобные «узкие места» в работе базы моделированием ситуации с использованием встроенного замера производительности 1С там достаточно одного нажатия на будильник и в конфигураторе вы увидите где именно происходят задержки выполнения, это намного легче чем использование сторонних средств, да и далеко не всегда базы 1С крутятся именно на MS SQL.
Но в целом автору статьи большой респект за описание методики и модели оценочного преобразования запроса T-SQL в аналог запроса языка 1С.
(3) kilokilo,
Мы увидим оптимизированный запрос движком 1С. SQL Server оптимизирует план выполнения запроса, при этом текст T-SQL запроса переданный 1Сом не меняется.
(4) eligor,
замер производительности — это очень хорошая вещь, но он покажет только производительность в конкретном сеансе и в конкретной среде работы сеанса. А отловленные запросы профайлером могут указать и на сам проблемный сеанс (например, сеанс пользователя с существенно отличными от остальных пользовательскими настройками) и на проблемные условия в среде в которой работает сеанс (время дня, когда выполняется закрытие смены другими пользователями и т.п.).
Обычно «проблемные условия в среде в которой работает сеанс (время дня, когда выполняется закрытие смены другими пользователями и т.п.).» выявляются опросом пользователей, в 99% случаев сами-же пользователи и обращаются.
И как скажите мне профайлером вообще можно оценить конкретный сеанс!???? Только источник увидеть, т.е. пользовательскую машину, а если БД на управляемых формах, либо WEB приложение!?
Профайлер вещь хорошая…, но количество запросов которые «сыпет» 1С в БД MS SQL оооочень велико, для отрисовки справочника например на 1 обновление 1С делает 2(ДВА) запроса один по колонке сортировки, другой по сортировки UIN-ов, для чтения регистров от 4 до 6 запросов), и довольно проблематично выявлять запросы с большим количеством duration’s либо reads’ов вот это бы автоматизировать…
Да и повторюсь MS SQL как среда развертывания баз 1С далеко не панацея.
Invaa 27.07.12 10:06
(3) kilokilo,
«SQL Server оптимизирует план выполнения запроса» — ужас люди!!!! SQL Server не оптимизирует план запроса, он ЕГО СТРОИТ!!!!
А вот то, что 1С параметризует запрос это очень хорошо, но все равно кэш запросов довольно быстро растет, потому что в 1С все равно их много.
Как вариант использовать ключи сеанса типа /clearcashe и сброса пользовательских настроек непосредственно в БД MS SQL 1С таблички Config, ConfigSave, v8users, Params и !!! Files, но это крайне осторожно, не забывая о версионности объектов и ссылок.
Ни разу не приходилось прибегать к профайлеру. Все проблемы с производительностью решаются с помощью шаблонных решений оптимизации запроса. Такие как — не обращаться к данным в базе более 1ого раза. использовать индексы, иногда помогает разбивка запроса на более простые части. и т.д.
(8) eligor,
прежде чем капс-локить на кого-нибудь, разберитесь в мат. части…
/ClearCache — очистка кэша клиент-серверных вызовов. На кеш запросов (имелась в виду статистика оптимизации в ms sql server?) этот параметр не влияет.
вот вам статья на «почитать» про оптимизацию плана выполнения запроса ms sql server:
и еще интересная статья Гилева
(10)
Ну хорошо, хорошо не буду спорить по поводу /ClearCache , сами надеюсь почитаете про него, он же ведь не влияет на сам MS SQL в общем, а только какой-то сброс для одного рабочего места, правильно? А по поводу оптимизации планов запросов… ну тут поспорить можно, вот я себе как-то смутно представляю при чем тут оптимизация запросов на самом SQL? Из 1С-ки формируется запрос, уже переведенный в T-SQL, для него строится план выполнения 1,2, и т.д. (строит сам MS SQL) и на основе статистики в данный момент времени сам MS SQL и выбирает какой ему лучше использовать план, либо построит новый. Но все это лишь бла бла бла, на самом деле наверное все-же лучше правильно организовать построение и хранение данных в самой 1С и по возможности избегать написание монстроидальных запросов(в 8.3 корректно поддерживается более 400 уровней вложенности запросов дерзайте), для полей(реквизитов, измерений и т.п.) связи и условий выборки лучше вводить индексы, ну и тому подобные несложные вещи. Повторюсь MS SQL не панацея! и у микросовта всегда был свой взгляд на «разработку и реализацию» любых комплексов и серверов… эх ка бы не удачная реализация офисной печати+пакет офисных програм… глядишь винда была бы и не такая популярная, не зацикливайтесь на ней
(10)
Цитата из вашей ссылки от Гилева
Поиск длительных запросов SQL Server Profiler-ом
Последний способ для страдающих ностальгией по 90м годам, когда администраторы баз данных куда больше ценились (и это было вполне обосновано). Способ не то чтобы для извращенцев, но квалификации требует наибольшей из всех перечисленных здесь способов, а эффективность не гарантируется.
(7) ты это точно трезвый написал?
Вопрос в тему… вы спросили трезвый оценивает свои результаты по выполнению кем то другим сформулированным условиям и логики. и еще раз перечитайте тему. А так — можно ли решить вопрос — кто то ставит условия и задачи, другой их формализует, третий их ставит в очередь(в порядки формализации или плана запроса), четвертый обрабатывает ну и пусть даже возвращает результаты — вы думаете это можно сложить в одно — «ответственного» и где то там найти ответы?
(9) Подтверждаю. По опыту лучше 2(3,4..) запроса и внутреннея логика(обработка данных), чем один запрос, быстрее больше чем в разы. Да и вообще SQL и тп запросы не слово божье, данные можно и подправить на лету и индексы сбить… SQL-фобы — сектанты