Запрос по таблице значений.... #283944

Подскажите пожалуйста как запросом можно сделать выборку из таблицы значений?:(

В 8.0 - никак

К сожалению никак, потому что ТЗ не объект конфигурации

Блин...плохо...очень плохо...

По моему 8.1 может помочь

, Построителем отчета

хрен ты ее еспользовать в таком случае сможешь (например соединить с чем-нить)...

+ Или построителем запроса...

Такого условия использования ТЗ в не заявлено, читайте внимательнее

по опыту, именно это обычно и надо. А вам лишь бы сказать - какие все вокруг дураки...

и хоть по 10 ТЗ выборку делай с любыми объединениями :) (читайте мануалы)

+ и учите язык запросов

с этого места подробнее пожалуйста. Может, пример приведешь? Код рабочий?

По опыту обычно этого и не надо...

значит, ты просто не сталкивался с такими ситуациями...

Логично, блин!

Конструктор запроса вроде как работает либо только с ТЗ либо с данными из БД. Но!!! В каком то релизе была ошибка (12 или 13) и платформа позволяла выполнять запросы: ВЫБРАТЬ ИЗ &ТЗ Потом исправили. В 8.1 можно пользовать временные таблицы.

обычная ситуация - ТЗ формируется в обработке (например на ее форме) и надо эти данные соединить с какими-то данными в таблицах БД... Это было баг в древнем релизе. Так что не принимается как ответ на . Хотелось бы услышать, что имел в виду ВикторБ...

Так и передавайте колонки Вашей ТЗ как условия отборов в запрос. Зачем соединять не соединяемое?

Потому что одной колонки недостаточно. Из ТЗ нужны предположим связки Номенлатура+Количество...

+19 сплошь и рядом в конфе есть запросы, где используются такие конструкции для записанных доков (есть в БД таблицы, откуда можно эти данные брать в связке). А из ТЗ хрен ты такое возьмешь...

соединять таблицы по полю количество? очень интересно узнать, что за задача решается...

предположим, нам надо контролировать остаток товара не при проведении документа, а на стадии его создания из обработки РабочееМестоМенеджера... Да мало ли еще вариантов...

"нам надо контролировать остаток товара не при проведении документа, а на стадии его создания" ну так и контроллируйте на стадии создания. зачем джойнить ТЗ с таблицей из базы для этого?

Да потому что проще эти данные получать непосредственно в запросе, если это возможно, а не потом обходить и проверять. Не говоря о том, что КонтрольОстатков для такой структуры уже написан в типовой (если данные берутся из базы). Я хочу сказать, что обойтись то конечно можно как правило, но иногда вместо прямого получения нужных данных в запросе, приходится в запросе получать избыточную инфу и потом мучительно ее обрабатывать...

Так храните данные в правильном месте. Мне кажется, что Вы сами себе создаете проблемы, чтобы потом их "героически" преодолевать...

Так храните данные в правильном местеи проблем не будет. Мне кажется, что Вы сами себе создаете проблемы, чтобы потом их "героически" преодолевать...

(25,26) т.е. ты предлагаешь при использовании обработки записывать эти вспомогательные данные в БД? Не красиво это...

Я предлагаю при проектировании обработки подумать о том, как будете читать данные

ну предложи пример. Как можно спректировать обработку, чтоб удобно решить эту проблему?

+29 итак?

а в ответ тишина...

Храните данные в одном месте, а не в куче разных. Например, храните все в памяти или в БД, или в файле...

Извините, что не отпрасился у Вас в туалет...

Одна ТЗ - это куча разных мест? Ты предлагаешь чисто вспомогательный инструмент сделать хранимым? Уж лучше тогда получать в запросе избыточные данные и потом их обрабатывать ИМХО...

Если все данные лежат в одной ТЗ, то необходимости соединения ее с таблицами не возникает...

как это не возникает? я тебе пример привел...

Да, Вы привели хороший пример неудачного планирования структуры данных.

я не увидел у тебя предложения - как спланировать удачно. Для данного конкретного случая предложи.

Так опишите конкретный случай и конкретный ожидаемый результат.

есть обработка, в форме которой по некоторому принципу отбирается товар, его количество и возможно какие-то еще данные. Затем по нажатию на кнопку автоматически формируется документ продажи, если этого товара хватает.

А если товара не хватает, то что?

есть варианты. В простейшем случае говорим - чего не хватает и посылаем. Можно вариант с заменой на аналог предложить (если его хватает)...

Если остатков товара хватает, то что делаем с документом продажи? Проводим, записываем, показываем, печатаем?

создаем и показываем. У пользователя есть произвол - записывать его или нет...

Если я правильно понял, у нас есть: - Остатки товаров, лежащие на сервере, где-то далеко в сети - Список товаров в памяти пользовательского компутера и желаемое количество списания по каждой позиции Хочется: - В памяти пользовательского компа создать документ продажи, заполенный выбранным товаром и указанным количеством по каждой номенклатурной позиции - Если запрашиваемое количество какой-то позиции превышает остатки на складе, то выдаем ошибку "Обратитесь к системному администратору" и кладем систему - После заполнения документа, открываем его форму Возможное решение: Получаем запросом остатки нужных нам номенклатурных позиций. Перебираем результат запроса и для каждой строки проверяем соответствие количеству табличной части обработки. Если проверка не проходит, то выводим сообщение об ошибки и кладем систему. Открываем форму документа.

я тебе уже написал об этом в . Понятно, что все это можно сделать. Но если бы была возможность работать с ТЗ в запросе, то решение было бы проще и по написанию кода и по скорости исполнения...

Такое решение не было бы проще. Оно было бы таким же трудоемким пока 1С использует SQL сервера сторонних производителей...

ставим 11 релиз - в нем можно было использовать таблицу значений... или переходим на 8.1

тут спорить не буду. Вопрос о производительности еще смотреть надо. Но написание кода было бы на порядок легче...

т.е. можно бежать впереди паровоза в надежде что не задавит или прицепиться к нему сзади в надежде, что не свернем шею.:)))

Написание кода было бы ровно тем же по трудоемкости, ибо перед выполнение хитрого запроса надо все данные "свалить" в одно место (например в одну БД). Процедуру для этого "сваливания" надо писать. Не могу понять, почему эту простейшую процедуру Вы не можете написать сами и почему ее должны писать обязательно в 1С...

в смысле? какие данные куда свалить? Мне пришлось делать как в . Если бы я мог в запросе использовать ТЗ, то я бы получил нехватающие позиции сразу в запросе.

Не могли бы Вы подробнее объяснить как SQL сервер будет в запросе использовать данные, находящиеся в памяти стороннего приложения, где-то далеко в сети?

а как это делается с временными таблицами в 8.1?

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

Не видишь принципиальной разницы в производительности или в написании кода? Временная таблица для использования ее в запросе создается в коде как? Одним оператором? Ты не видишь разницы между этим и отсеиванием после запроса всего лишнего?

Так и в 8.0 я могу в своем коде вызвать процедуру, которая зальет мою ТЗ, в какой-нибудь регистр сведений (это уж если потянуло на извраты). На читабельность кода это не повлияет, а производительность зависит от слишком многих факторов, неоговариваемых в нашем примере...

заливать эти данные в хранимые - это действительно изврат, поэтому решение выглядит лучше. Но если бы на уровне платформы была такая возможность, как в 8.1, то было бы еще проще. Поэтому и говорю, что, хоть выход и есть всегда, но бывает, что он либо трудоемкий, либо извращенный. А ты говоришь, что не всречался с ситуациями, где эта возможность могла бы пригодиться...

Да какая разница на каком уровне(платформа или конфигурация) сделано это решение? Доступ к процедуре будет одним и тем же. До сих пор не могу вспомнить случая, где такая возможность была необходима, ведь даже в Вашем примере проверку остатка можно поставить в момент подбора номенклатуры и тогда вообще никаких связей между таблицами не понадобиться...

умгу. И вместо 1 запроса использовать 100...

Ну если учитывать все обращения к базе, то запрос будет явно не один. А если для заполенния ТЗ использовать форму подбора с остатками, то количество запросов к базе будет не велико.

в смысле не один? Имеешь в виду, что обращения будут идти к нескольким источникам? Ну и что? Если контроль на стадии заполнения использовать, то количество запросов увеличится в (количество позиций номенклатуры) раз. Разве нет?

При желании, количество запросов можно сократить до 1-ого. Но тогда придется писать свою обработку подбора.

Форму подбора с уже заполненными остатками? Можно. Но мы снова пришли к увеличению трудоемкости. Разве нет? Еще раз говорю, что все это можно при желании обойти. Но вопрос удобства в таких ситуациях...

Какая еще трудоемкость? Делается за 5 минут, т.е. много быстрее, чем мы тут это обсуждаем.

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

остатки только по выбранной номенклатуре в форме подбора - это сильно сказано! это 5!

выбранной - относится к случаю, когда я сначала выбираю номенклатуру, а потом для нее проверяю наличие остатка. Т.е. я сравниваю твой вариант формой подбора и предыдущие обсуждаемые варианты. По-моему все нормально написал...

"сначала выбираю номенклатуру, а потом для нее проверяю наличие остатка" - это не столько лишние запросы к базе, сколько лишние действия для пользователя, а значит больше возможности для внесения ошибок в данные, и большие требования к защите от дурака. Поэтому я бы подобную задачу решал через форму подбора с остатками - это и не привело бы к лишним запросам, сразу бы информировало пользователя, а не задним числом, и не потребовало бы лишних соединений ТЗ с БД.

Но раз Вам принципиально именно возможность свзи ТЗ с БД, то на решении я не настаиваю...

думаю, запрос на остатки по всей номенклатуре все-таки не всегда приятная вещь. Ладно, закрыли тему. Надоело. Остаюсь при своем мнении, что есть ситуации, когда удобно использовать ТЗ в запросе...

Вот кстати еще мысль пришла. Предположим, в той же задаче надо осатки иметь не просто по номенклатуре, а по связке измерений Номенклатура+Характеристика. В ТЗ обработки предположим 100 строк с указанными комбинациями номенклатуры и характеристики. Без возможности использьования ТЗ в запросе ты получишь выборку 10000 строк (все комбинации указанных номенклатур и характеристик), из которых тебе потом придется найти по составному ключу 100 нужных. Даже с учетом времени загруки исходной ТЗ во временную таблицу запрос с ТЗ будет работать на порядок быстрее, чем такой алгоритм. Критикуй...

Куда оппппонент делся? Ау! :))

Ок. Критикую. На мой взгляд выделять проверку в отдельный шаг - это плохо. Пусть проверка будет совмещена с моментом выбора номенклатуры. Сделай подбор номенклатуры с характеристиками и остатками и проверяй количество при подборе. И опять не нужно будет лепить запрос по ТЗ соединенной с БД. P.S. Если Вы еще и про остатки по складам вдруг вспомните, то я скажу, что и склад можно добавить в подбор. Если же Вы дальше продолжите развивать тему добавления полей в обработку, то супер-подбор номенклатуры органически соединится с этой самой обработкой... Оппонент иногда спит...

и опять скатываемся либо к большому количеству запросов, либо к одному, но с немеренным количеством лишней инфы. Кроме того, бывают еще навороты, связанные с автоматической заменой товара на его аналог в случае нехватки. Поэтому отсутствие нужного количества товара в форме подбора еще ни о чем не говорит...

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

это как раз требования пользователей. И система с такой заменой в формируемых документах нормально работает...

Таких требований раньше не заявлялось. Начнем проектирование сначала. Объявите новый список текущих требований.

раньше не заявлялось. Но пользователи тоже постепенно добавляют все новые и новые требования. В случае, если у тебя уже есть работающий вариант и пользователи в какой-то момент захотели работать с аналогами и попросили доработать, ты будешь перепроектировать все с нуля?

Нет, я буду сразу проектировать с учетом возможных вариантов развития ситуации. А добавить возможность использования заменителей в форму подбора никаких проблем не представляет. Мало того, при этом у пользователя окажется возможность управлять использованием заменителей, а в Вашем варианте такой возможности не видно...

А ты мог предугадать при той постановке задачи, которая была, что будет такой вариант развития ситуации? Сильно сомневаюсь. Все варианты предугадать в любом случае невозможно. А насчет управлять использованием - по требованию клиента его не должно быть. Обработка должна иметь как можно меньше управляемых моментов, поскольку расчитана на не очень квалифицированный персонал (должна быть простая как молоток)...

Возможность управлять - это не означает, что обработка будет сложной. Рано или поздно возникнет ситуация, когда квалифицированному сотруднику понадобится возможность управления. Система не должна встать в такой момент. Да и отключить для отдельных категорий пользователей функционал очень легко. А вот срочно добавить функционал - обычно трудно... Да и все варианты предугадывать не зачем, достаточно предугадать 90%, а это легко.

Можно. При желании все можно. Т.е. ты сразу на стадии начальной задачи вместо того, чтобы сделать 1 инструмент, будешь ваять трансформер с возможностью работы в 100 разных режимах... Ну чтож, вперед и с песней...

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

Ладно, опять скатились к спору ни о чем...

Да какой тут спор? Есть инструмент, можно его использовать, можно не использовать. Можно валить на него свои сложности, можно не валить. Каждый для себя выбирает свой путь и способ...

ладно. Попробуем придумать другую ситуацию. Предположим, есть некоторый документ, у которого есть к примеру в ТЧ те же Номенклатура и Характеристика. Создаем строки, указываем в них Н и Х. Потом жмем на кнопку "Заполнить", которая для введенных Номенклатур и Характеристик выбирает данные из некоторого регистра и заполняет еще какое-то поле ТЧ (например количество). Хотим, чтобы это работало для новых доков с возможностью НЕ ЗАПИСЫВАТЬ документ в базу. Как будешь решать?