<?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='\
Если текст запроса наращивается через менеджер временных таблиц, то в этом случае все также не возможно посмотреть и другие таблицы в менеджере и весь итоговый текст запроса.
Так?
(1) Makushimo, Не совсем поняла вопрос.
Через менеджер запроса текст не наращивается.
Менеджером можно объединить несколько отдельных запросов или пакетов, чтобы они использовали одни и те же временные таблицы.
При формировании запросов, связанных одним менеджером, мы не видим в конструкторе таблиц, связанных с этим менеджером в других запросах.
по первому примеру — для решения такой задачи я поступаю так:
1. в запросе условие:
2. параметры запроса:
выглядит читабельней, как мне кажется. И запрос «рвать» не надо — все прекрасно отрывается в конструкторе.
но тема интересная — надо покопаться на досуге.
(3) nihfalck, На самом деле способов много
Они подробно описаны тут
Они хороши, когда мы говорим об 1-2х изменениях.
Но каждая такая модификация все-таки усложняет понимание кода и часто немного замедляет выполнение запроса.
Чем сложнее запрос, тем менее допустимы такие вещи.
…и понеслось…
Жили мы без этой фичи множество времени и дальше проживём. Выморочная вещь, для галочки сделанная.
Вы что, всерьёз верите, что изменять или хотя бы понимать запрос станет проще? Ни разу. Вот увидите, как писатели типовых конф, получив сей инструмент, превратят один ранее заданный куском запрос в нечто, собираемое десятью процедурами, и понять что-то станет ещё тяжелее.
(1) Присоединяюсь к вопросу.
Да, хорошая идея для сложны и/или динамических запросов (научиться бы этим еще пользоваться)
Можно использовать и для простых запросов — когда надо прочитать реквизит документа из базы чтоб лишний раз не дергать ссылку (т.е. считывать весь набор данных) просто написал запрос, который из метаданных объекта формирует запрос к нужному реквизиту документа.
как пример
Показать
В структуре список реквизитов, которые надо выбрать — используется что бы проверить на изменение реквизитов по сравнению с сохраненными в базе
Я вижу такие применения объектной модели запроса
— внесение точечных модификаций в тексты запросов поставщика для облегчения обновления конфигурации от поставщика
— полные/частичные генераторы текстов запросов
— визуальные средства разработки запросов
хотелки))
если разработчики платформы добавят в стандартный конструктор запросов вывод не только текста, но и кода построения схемы — то это будет хорошо)
(5) Yashazz, Я не совсем поняла вопрос из (1)
Запросы, связанные через менеджер, это разные запросы, работающие с общими временными таблицами.
Насколько я понимаю, через схему запроса мы не можем получить доступ к тексту другого запроса, использующего этот же менеджер.
(9) caponid, собственно, стандартный конструктор запросов это и есть визуальный интерфейс к объекту «Схема запроса». Он выводит все свойства объекта и через него мы можем визуально их просматривать и править.
Чего в нём еще не хватает?
Читал ранее про данный механизм «склеивания» запроса из кусков кода по-человечески. Вроде бы благое дело сделали разработчики платформы 1С 8.3.5, но вот как делал «склеивание» из кусков текста так и буду делать. Почему? Механизм «схема запроса» только вышел и 100% сыроват и там точно есть пара глюков которые на самом виду и которые специально никогда не исправят. Это же не мобильная платформа, не http-сервисы или внешние источники данных которые если начали использовать придется терпеть и обходить баги смекалкой одинэсника 🙂 Придется подождать хотя бы публикаций о багах данного механизма, который очень сильно напоминает программное формирование отчета на СКД: те же сложные типы данных, составляем вручную поля, отборы…
Следующий вопрос: на каком принципе можно получить связи запроса для построения графа?
(11) kostyaomsk, Никто не говорит, что нужно прямо сейчас всё бросить и начать переписывать все запросы через схему запроса.
Просто учитываем, что есть такая возможность и со временем её начнут использовать в типовых.
По поводу графа.
Просто выписываем из СП, какие у объектов есть свойства и какие типы данных допустимы для этих свойств.
Потом просто в текстовом виде связи скармливаем связи графопостроителю. Он уже размещает элементы на листе.
Автоматического определения нет.
Я выписывала для себя в Ексель для этой обработки
В ней же выложен приложением исходный текст для графопостроителя и ссылка на него.
Инересно, на каком уровне всё-таки формируется итогоый SQL-запрос и нет ли в планах добавить к этому механизму отображения SQL-запроса. Если была бы возможность редактировать итоговый запрос к БД — это было бы крайне полезно.
(2)
Очень часто писатели конфигураций используют менеджер временных таблиц для динамического построения одного запроса.
Просто запросы пакета разбросаны по всей конфигурации.
А часто во время отладки хочется понять в каком запросе нужно изменение внести или ошибку найти.
приходится ползать по всем модулям вслед за отладчиком и копипастом в консоли выстраивать весь огромный запрос. Дальше уже с ним баловаться.
Гораздо полезнее было бы реализовать просмотр содержимого Менеджера ВТ — и результата и текста запроса.
А так эта новая фишка делает нечитаемый код динамического запроса еще более нечитаемым.
Может это привыкнуть надо.
Новшество интересное. По хорошему надо вообще переходить на декларативное описание всего интерфейса 1с на базе XAML. Вот тогда и откроются для разработчика широчайшие возможности для визуализации, отвязанные от чудачеств нынешних творцов, придумывающих свои уникальные велосипеды вроде «Такси»
Описание, наверное, будет не полным. Если не упомянуть метод УстановитьСхемуЗапроса(ТекстНаписанногоВКонструктореЗапроса)
То есть, можно сначала написать, большой запрос Конструктором. Затем загнать его в Схему, и уже там работать с теми вещами, которые необходимо Алгоритмизировать; Очень крутая штука, не удивлюсь, если через год, это станет стандартом, для программной работы над Запросами!
(14) Oleg_nsk, ну собственно новый REST-интерфейс Вам в помощь, ну и собственно на базе веб-сервисов можно было пилить свой фронт для нетиповых спокойно. Проблема только в том, что сегодня пилить фронты из 1Сников могут не только лишь все. Мало кто может это делать.
Интересный механизм, но практическую пользу понять сложно.
Разработчики давно наловчились динамически делать и менять непосредственно текст запроса, так что вряд ли оно получит широкое применение для того, чтобы что-нибудь изощренно спросить у базы.
Зато в качестве парсера текста запроса (если я правильно понял) вещь незаменимая. Ты ему строку, а он тебе в объект разложил. Красота!
Но зачем это может быть нужно? Сходу не соображу. Писать автоматические переводчики с языка запросов 1С на другой язык? На какой?
Новая супер-консоль запросов, которая более корректно и точно представляет запрос в виде дерева и имеет дополнительные плюшки-навороты? Может быть.
Где еще может быть нужно распрасить текст запроса?
(13) baloo, Мне тоже интересно. Думаю, окончательный вариант текста запроса все-таки за пределами сервера 1С. Не думаю, что целесообразно его редактировать вручную. Слишком разные варианты будут оптимальными в зависимости от данных.
(15) Makushimo, Через схему, к сожалению, такое сделать нельзя. Так как она сейчас все-таки строится на основании текста запроса. Менеджер, грубо говоря, всего лишь связывает запросы в одно пространство, чтобы они использовали общие данные. Но запросы остаются отдельными запросами.
(16) iTony73, Да, мне оже кажется, что схема более применима для модификаций имеющегося запроса, а не для создания с нуля. Вроде эту мысль в статье высказывала.
(18) zfilin, Разработчики научились. Но те запросы с собирание пакета из кусочков, что используются сейчас в проведении типовых, как раз имеет смысл формировать через схему. Не думаю, что будут менять имеющиеся, но со временем новые вполне можно формировать программно.
Писать свой конструктор смысла не вижу. Типовой, на мой взгляд, достаточно удобен. Не думаю, что можно написать на УФ его лучше, чем программисты платформы написали на Си.
(10)
Чего в нём еще не хватает?
Насколько я понял, хотелка заключалась в автоматической генерации не только текста самого запроса, но и кода построения объектной схемы. И это хорошая хотелка, на мой взгляд. В разы сократит генерацию кода для последующего изменения ))
(21) MaxDavid, Я недавно писала обработку по генерации дерева объекта «Схема запроса». В статье ссылка есть. Технически проблем корректной генерации текста схемы нет, можно сделать.
Собственно, один вариант уже есть. Сегодня видела на инфостарте обработку конвертер. Правда, пока не совсем рабочий.
Пока не вижу реального применения такой автогенерации.
(20) К сожалению, не вижу принципиальной разницы для «читабельности» между
и
Что касается типового конструктора. Да, удобен. Но посмотрите консоль запросов в инструментах разработчика. Отличная вещь.
Непосредственно конструктор там используется стандартный. Но кое-какая работа с текстом запроса идет.
(23) zfilin, Из преимуществ программного добавления:
1. Если мы добавляем условия в имеющийся запрос, то с программным добавлением текст исходного запроса не разрывается и его можно открыть конструктором.
2. Эти два варианта примерно эквивалентны, если мы говорим о добавлении одного условия. Если их десяток (по складу, организации, подразделению, номенклатуре….) и нужно добавить лишь несколько из этого десятка, в зависимости от условий, то програмное добавление удобнее.
3. Схема удобнее, если нужно удалить условия или поля. При любой модификации она остается синтаксически корректной. Например, если мы удаляем колонку, то она автоматически удалится и в выбранных полях и в итогах и в группировках. Вклиниванием в текст пришлось бы вклиниваться в несколько мест.
Разумеется, во многих случаях стандартные варианты удобнее. Я просто предлагаю еще один вариант работы.
Инструментами разработчика пользуюсь, но реально использую очень небольшой набор функционала. Хотя вещь великолепная. Заменяет набор различных обработок.
(23) Уже год как в инструментах разработчика есть свой навороченный , который в явном виде не предоставляет программной модели, но фактически она там есть.
А дерево запроса заточено на анализ и отладку, т.е. на работу со всеми блоками текста запроса, которые можно выполнять отдельно.
(24) Убедительно. Посмотрим что будет. =)
(25) tormozit, Посыпаю голову пеплом, пользуюсь старой версией. А, может, и просто не включал. Но даже там, чем пользуюсь, есть дерево запроса. Отличная вещь.
Собственно об этом и говорю. Запрос разбирается в объектную модель, чтобы предоставить больше возможности для представления разработчику и отладки по-частям.
А как он разбирается? Схемой запроса?
(27) zfilin, в ИР запрос разбирается с помощью COM реализации движка GoldParser и самодельной грамматики для языка запросов. Объект СхемаЗапроса появился несколько месяцев назад. Поэтому ИР никак не могла на него опираться до его создания =)
(28) tormozit, Ну вот. =)
(19) не может быть формирование результирующего SQL-запроса за пределами сервера приложений — ему быть больше негде, разве что в скульных хранимках, но разработчик, к счастью не стал на них завязываться, иначе Postgres и DB2 мы бы не увидели.
Поэтому я думаю рано или поздно это будет реализовано.
Делал ещё когда в ИР не было своего конструктора запросов (но парсер уже был и дерево запроса строил). Разбирал строку сам, без ВК — только хардкор :-)) Кстати, сделано за одну бессонную ночь ))
Я пока тоже не понимаю прелестей объектной модели. Да, текст запроса не рвется на условие — может быть, эстетически это лучше выглядит.
Меня, например, в рвущемся запросе сильно раздражает — что конструктор запроса из конфигуратора не открыть — приходится включать отладку, выдергивать полный текст запроса непосредственно перед Запрос.Выполнить() — и на нем уже открывать конструктор. Я так понимаю, со схемой запроса ситуация ничуть не улучшилась, верно?
Опять же — рвем запрос, как правило, для условного отбора, чтобы работал побыстрее. Есть вариант менее производительный (флаг отбора и отбор объединены по ИЛИ. или как вариант — оператором ВЫБОР):
|ВЫБОР
| КОГДА &ИспользованиеОтбораСклад
| ТОГДА СправочникСклады.Ссылка = &Склад
| ИНАЧЕ ИСТИНА
| КОНЕЦ
В этой ситуации здорово было бы, чтобы оптимизатор понял, что флаг — это константа в запросе, его можно вычислить 1 раз до выполнения запроса и не выполнять проверку условия СправочникСклады.Ссылка = &Склад, если из-за флага туда исполнение не зайдет.
Но он так не умеет и поэтому работает медленнее. И поэтому приходится делать некрасиво, зато быстро
Если флагОтбора Тогда
ТекстЗапроса = ТекстЗапроса + » СправочникСклады.Ссылка = &Склад»
КонецЕсли;
Со схемой запроса получаем абсолютно тоже самое.
Странное направление развития у 1с. Казалось бы, могли бы поправить вычисление «констант» и все за это сказали бы спасибо. Могли бы добавить нормальное количество строковых функций в запросах (почему-то в любом SQL их предостаточно, а 1с решила пойти по пути минимализма). Могли бы добавить возможность вмешиваться в генерируемый на чистом SQL запрос — например, программист смог бы делать грязное чтение — иногда точность последних данных не критична, зато быстрее. Но 1с вводит сомнительные улучшения.
(3) а так не проще?
(31) DrAku1a, Видела Вашу обработку. Красиво сделано.
А вообще давно по себе заметила, что все интересные вещи делаются сразу. Т.е. продумал, сел и написал. Если пытаешься что-то сделать и оно не получается или получается слишком запутанно, то значит плохо продумал, не хватает теоретического понимания темы. Тогда нужно не лепить заплатки, а просто отложить и сделать потом.
(32) mixsture, Если мы формируем запрос текстом и лишь програмно добавляем условие, то он отлично открывается конструктором. Написать «ТекстЗапроса = ТекстЗапроса+<Условие>» мы можем лишь в случае, если условие нужно в конце текста. Если запрос пакетный либо есть итоги, то условия в конец дописать нельзя. Только разрывать запрос.
По строковым функциям согласна, мне их тоже не хватает.
По чтению вроде ж сделали. ИМХО, версионное чтение в 8.3 лучше, чем просто грязное чтение. Данные целостные, блокировок нет и на производительности не сказывается.
(33) wolfsoft, Проще. Но такое условие отменяет использование индекса по складу. В некоторых неудачных случаях время выполнения увеличится на порядок. При выборе из справочника пофиг, при выборе из РН с миллионами записей это может быть критично.
+ толково и понятно. спасибо
(34) согласен, запрос открывается. Но программно наложенных отборов в нем не видно. А отборы — очень важная часть запроса. Не видеть их — тоже как бы плохо.
И таким образом поиск ошибок абсолютно не меняется — встаем отладкой перед Запрос.Выполнить и смотрим текст запроса.
Идеальным было бы научить сам объект Запрос корректно оптимизировать условия «флагОтбора или отбор». Тогда можно не рвать запрос и все хорошо открывается в конструкторе, а также все составляющие запроса сразу видны в 1 месте.
(32)
(8) tormozit, для «точечного изменения» тповых, чтобы потом обновляться?
никогда так не делайте!!!
расскажу почему:
был запрос
Вы его поменяли этим чудом
Вышел новый релиз и запрос поменялся
Вы при тройном сравнении увидели свои новые строчки, и скопировали их
А в запросе изменился кто-то
Ваши строчки кода модифицируют не те поля и не так, причем, не факт, что будет ошибка и возможно все продолжит работать, но не так как надо.
Можно напороться на семантическую ошибку, программа работает без сбоев, но результаты получаются неверные
(39) monkbest, известная, но при определенных условиях способ может давать неплохую надежность.
Не дай бог в типовых начнут применять
Я уже наелся, когда в отчете на схеме компановке на кой-то хрен подменяют перед формированием запрос, получая его из общего модуля при этом несколько раз применив к тексту «СтрЗаменить(ТекстЗапроса,…,…)» и вызвав 10 вложенных функций.
Итак в этой каше отлаживаться и добавлять свой функционал — огромные трудозатраты.
А теперь вообще жесть будет.
Возьмут они текст запроса и будут его потом кодом модифицировать. А как мне его конструктором посмотреть, чтобы понять, что они там получают?
А как мне свои поля протаскивать через 20 временных таблиц после такого изврата над запросом?
Для масштабируемости решений главное — читабельность, а это новшество уничтожает читабельность.
(40) tormozit, согласен с «но при определенных условиях», уверен, что будут случаи, когда это будет надежно, читабельно и оптимально. но это не про типовые конфигурации:)
(41) надеюсь в типовых оставят нормальные тексты запросов, а это чудо предложат использовать для модификации типовых решений, например, в не меньшем чуде — расширении конфигуратора, чтобы не «портить» исходный текст запроса
(43) yandextesting, Насколько я понимаю, через расширение конфигурации доступа к переменным не будет. Только к объектам. А схема запроса в данном случае просто переменная.
Схема запроса более стандартный механизм. Думаю, будут использовать в типовых решениях.
(42) У любого механизма свои плюсы и минуса. Просто им нужно уметь пользоваться.
(45) Нет, коллега, речь идет не о том.
Есть мнение, что у этого механизма плюсов просто нет. Никаких. Именно это и пытается донести не восторженная часть сообщества.
А подходом «Просто им нужно уметь пользоваться», ну давайте на ассемблере теперь писать и с базой работать. Сплошные плюсы — контроль полный, производительность сумасшедшая, просто «пользоваться надо уметь».
(46) zfilin, не забывайте, что без ассемблера не было бы языков более высокого уровня. Можно говорить о том что ассемблер не юзабельный и кому он нужен, а можно расматривать как плацдарм для дальнейшего расширения функциональности. Не все нововведения приносят прямую явную пользу конечному потребителю, некоторые могут быть совершенно бесполезны на первый взгляд, но при этом могут создавать мощную точку роста. Возможно это, своего рода голевая передача. Поживём-увидим, я думаю из этого может выпилиться что-нибудь стоящее.
(47)
И что? Каждому инструменту своё место. Не нужно микроскопом гвозди забивать. 1С был удобен для быстрой и комфортной разработки учётных программ. А сейчас он по своей громоздкости начинает приближаться к языкам высокого уровня. Скоро будет возникать вопрос, а зачем мне писать программу на 1С, если я тоже самое могу сделать на нормальном языке с нормальной объектной моделью без различных ограничений, накладываемых платформой 1С? У 1С в голове беда — она всё время пытается объять необъятное.
(47) baloo, Я и не забываю. Честь и слава пра-программистам.
(41) Точку останова ставите на Запрос.Выполнить() и отладчиком запросом или консолью запросов из ИР открываете (и там и там есть описание — как делать, в ИР это даже проще).
А объектная модель может быть использована для грамотного парсинга запросов в самых разных консолях — в т.ч. и под управляемые формы, т.к. с ней — не требуется извращаться с ВК. Можно написать свой конструктор запросов… Да много чего ещё можно сделать.
(48) По поводу громоздкости — согласен, не всегда удобно. Но и объёмы данных приходится представлять тоже немалые…
(48) Ну допустим, тоже самое на другом языке вы сделаете с превеликим геморроем, потому в 1С уже есть набор процедур, функций и классов, именуемых объектами метаданных.
(32) mixsture,
чтобы не городить в тексте запроса конструкций типа:
|ВЫБОР
| КОГДА &ИспользованиеОтбораСклад
| ТОГДА СправочникСклады.Ссылка = &Склад
| ИНАЧЕ ИСТИНА
| КОНЕЦ
Я добавляю в текст запроса равенство типа
ТекстЗапроса = «…ГДЕ 1 = 1 И 2 = 2…»;
Далее, анализ выбранных значений и при необходимости модификация текста запроса:
Если ИспользованиеОтбораСклад Тогда
ЗапросТекст = СтрЗаменить(ЗапросТекст, «1 = 1», «СправочникСклады.Ссылка = &Склад»);
Запрос.УстановитьПараметр(«Склад», ВыбСклад);
КонецЕсли;
гг, как минимум треть постов — это оправдания. Зачем?
Есть инструменты, которые позволяют что — то упростить, что то сделать (как сделано в типовых — сложить или заменить вставкой/заменой текста) иначе , или для «гиков» вообще через «что то с чем-то» — а то что предложили — это всего лишь тоже инструмент — а пользоваться или нет — это Вы сами решите для себя — я выбор сделал (все реально работает и позволило исключить навскидку 30-50% лишнего кода — вот тут (7)) — и по этому поводу «что это не тру» оправдываться не буду.
мда… отладка и правда затруднилась донельзя.
в общем-то поддержка измененных типовых усложнилась нехило.
теперь видать еще сложнее будет..
(46) zfilin, правильно! Потому 1с и проблемно-ориентированный, скрывающий реализацию, чтобы можно было спокойно думать о бизнес-логике! для каждой задачи — свои инструменты. Для систем реального времени — ассемблер и низкоуровневый си, а для учетных систем — 1с.
Немного не согласен по поводу терминологии:
Бирюзовым — примитивные типы, специфичные для схемы запроса;
Правильнее было бы:
Зеленым — примитивные типы (строка, число, булево);
Бирюзовым — системные перечисления, использующиеся в схеме запроса.
Спасибо за работу!
ИМХО желательно избавляться от констант при обращении к объектам по индексам, это очень часто приводит к ошибкам.
Прошу прощения, но прочитав публикацию и увидев:
>>изменение имеющегося запроса
Я подумал, что можно писать обычный запрос, а потом обратиться к его объектам и изменить что нужно, не разрывая, но в публикации не нашёл такой реализации. Это невозможно? Тогда подпишусь под комментаторами, считающими это нагромождением, тем более без штатного конструктора.
UPD: нашёл описание нужной реализации на сайте 1С, вот так делается:
Не то чтобы я злорадствовал, но — всем торопыгам на заметку: никогда не бросайтесь сразу осваивать новинки платформы. Вы с ними ещё намучаетесь, причём особенно благодаря оптимизациям и доработкам, каковые будут делать «вдогонку» их авторы — разрабы платформы.
Вот почитайте, сколько всего доработано по объектной модели запроса в 8.3.7, и подумайте — а стоило горбатиться раньше-то?
Терпение, терпение). Юзайте уже устаканившееся, меньше переделывать придётся)))
P.S. Считайте это моим общим ответом автору публикации, большой любительнице интенсивно копаться в каждой полусырой новинке)
в принципе, в (8) всё ответили по целесообразности
программно формировать таким образом запросы — это как программно формировать СКД — можно, но зачем?
трудозатраты на такую работу будут космические при сомнительного рода полезности
имхо, это полезно там, где возникает задача парсинга текста запросов — визуальные рендеры, построения моделей и прочего всего подобного
А теперь попробуйте добавить или удалить при помощи «Схемы запроса» условия виртуальных таблиц. Сразу вся хваленная стройность «модели» разваливается в старый добрый СтрЗаменить 🙁
(61) BurningChrome, Замечательно добавляются вообще-то.
(62) Это не добавление, а установка нового. Попробуйте добавить к «Организации», например еще «Контрагента»? А если надо к существующему условию:
добавить еще например
?
Красиво получается?
Передо мной стояла вполне реальная задача. Запрос выбирал во множество временных таблиц нужные мне данные. В результате мне нужно было получить всё содержимое всех полученных таблиц для последующей обработки. Причем, набор полученных в результате таблиц мне заранее не был известен, т.к. запрос в функцию передавался динамически. До появления объектной модели запроса мне приходилось регулярным выражением вычленять оставшиеся в процессе выполнения запроса таблицы, учитывая все ПОМЕСТИТЬ и УНИЧТОЖИТЬ, теперь же я могу не использовать внешние компоненты, хотя это и приходится делать несколько более громоздким способом. Таким образом я получаю структуру из нескольких таблиц в результате выполнения всего одного запроса.
Еще не приступил к знакомству к новому механизму, но спешу поинтересоваться вот чем:
1. есть ли возможность добавлять комментарии в создаваемый запрос через СхемуЗапроса (т.е. во время отладки при определении выражения переменной, присвоенной методом ПолучитьТекстЗапроса можно будует просмотреть запрос целиком, а что на счет комментариев в этом тексте)?
(5) Yashazz, Хорошо, а вот представьте себе ситуацию: вам необходимо НЕ МЕНЯЯ ЭЛЕМЕНТОВ ФОРМ (чтобы было проще обновляться) присоединить к запросам динамических списков нескольких десятков документов типовой конфы некую таблицу (скажем, регистр сведений МоиСтатусыОбъектов) и вывести поля Статус, ДатаУстановкиСтатуса. Как Вы это себе представляете без схемы запроса???
Любой сложный запрос, т.е реально сложный запрос, где в условиях сравнения используются не значения типа «равно», а >=,>,<,<=, где более 5-7 JOIN-ов и где очень хочется заюзать корреллируемый подзапрос (напомню, в 1С их нет!!!) лично я использую старую добрую консоль запросов и модель запроса составляю вручную. Как можно какой-то объектной схемой написать то, что я делаю на старом добром SQL у меня даже в уме не укладывается!!! Может я чего-то не до понял в языке запросов? Хм…
Всем привет! такой вопрос, подскажите пож-та!
В запрос в качестве таблицы-источника можно использовать таблицу значений, предварительно ее «типизировать» и передать параметром запроса, как такое провернуть используя схему запроса?
Пример:
Запрос.УстановитьПараметр(«ТаблицаИсточник «, ТаблицаИсточник );
…
«ВЫБРАТЬ
| ТаблицаИсточник .Поле1,
| ТаблицаИсточник .Поле2
|ПОМЕСТИТЬ ВТ_ТаблицаИсточник
|ИЗ
| &ТаблицаИсточник КАК ТаблицаИсточник
|;
…
(68) 1prog@bk.ru,
решено
ИсточникПакета0 = ОператорыПакет0.Источники.Добавить(Тип(«ОписаниеВременнойТаблицыСхемыЗапроса»),»&ТаблицаИсточник «);
еще Важный момент :
ОператорыТекПакет.ВыбираемыеПоля.Добавить(«ТаблицаИсточник .»+поле);
Может кому пригодится:
Добавляем в качестве источника вложенный запрос.
Здесь «Список.ТекстЗапроса» — это текст запроса динамического списка.
Показать
А где в схеме запроса хранятся условия вида {ГДЕ ….} т.е. в фигурных скобочках?
Столкнулся с интересной особенностью при модификации имеющегося запроса.
В запросе есть Полное соединение. Я хочу добавить еще одно.
Но при добавлении нельзя указать тип соединения, оно по умолчанию левое. Поэтому при вызове Соединения.Добавить() падает исключение «Противоречивая связь».
А можно ли из схемы получить текст отдельного запроса формирующего временную таблицу?
Как описать конструкцию
в схеме запроса, а точнее в операторе пакета запроса, что бы не перечислять все поля из источника?
налетел на проблему — пытаюсь менять запросы типовой конфы через схему запроса
так там используются комментарии, наподобие, «//ОператорПОМЕСТИТЬ»
которые, дальше, меняются на куски кода
при преобразовании в СЗ и обратно они теряются и усё приплыли ….. кто нибудь решал такую задачу ?
(76) Все верно, теряются, конструктор запроса сам производит форматирование и обрезает незначащие куски.