Добрый день!
Мне уже объяснили на форуме от 1С, что приведения числовых полей и полей типа дата в строку в запросе 1С НЕВОЗМОЖНО.

Это что, действительно так ?
И другого метода кроме как описано тут нет ???
http://catalog.mista.ru/public/331805/#comm

Просто это настолько ну распространенная операция для обычного SQL, что я не могу поверить в то, что нет возможности это сделать в запросе на 1С. Только без СКД!

Пример для понимания:
Вывести отчет с ОДНОЙ колонкой.
Именно одной колонкой, а не двумя и не тремя:
Продажа товаров № 333 от 12/12/2012 на сумму 233 руб 13 копеек.

В базе документ называется "Реализация товаров и услуг", номер имеет числовой тип, дату надо напечатать без времени через знак "/"

Только не начинайте пожалуйста полемику о том, что это не надо, что это вообще не надо так делать. Это просто пример, не более того. Вопрос стоит не в том, надо так делать или это вообще надуманная задача, вопрос стоит как БЕЗ_ИЗВРАЩЕНИЙ это сделать.

Всем хорошего дня :-)

без извращений - это тебе не в 1с.

Без извращений это делается на СКД. Если вы СКД считаете извращением, то вам надо работать над собой.

1С к сожалению такая, но можно генерировать в ПередЗаписью в отдельное поле

СКД - это хорошая вещь, но это обработка результата после запроса. И на самом деле СКД любить не обязательно, потому как всё что делает СКД делается уже на сервере 1С, а не на SQL сервере, и всё что можно посчитать в SQL запросе - правильно со всех точек зрения считать именно в SQL запросе, а СКД применяется только для оформления результата (и то, только в тех случаях, когда это оформление нужно)

Не надо мне генерировать ПередЗаписью, я хочу запрос сделать, чтобы соединял что мне надо и как надо и не хочу нарушать ту структуру данных которая есть. Возьмите любой учЁбник по SQL - там будет параграф - конкатенация строк и там будет оператор CAST - им можно и число и дату в строку переформатировать, и даже наоборот при определенных условиях строку в число можно...

(4) никто не заморачивается  с такой херней. Если вам надо сделайте в документе поле Комментарий. Туда пишите свое

"Продажа товаров № 333 от 12/12/2012 на сумму 233 руб 13 копеек."

а в запросе просто будет

Док.Комментарий

(4) ну нету, че делать то? там и Неопределено есть и пустые ссылки, а в SQL только NULL
и ссылочной целостности нет

но не умирать же из-за этого?

(6) В SQL есть ссылочная целостность )

(7) а в 1С нет

(8) как это? О_о

(9) битые ссылки видел в таблицах 1С?

(10) Я пробовал удалить элемент, а он не удалялся, ибо "есть ссылки".

А ошибки и физическое повреждение - могут быть в любой базе

(11) программно можно, в SQL запрет этого делается очень просто
(12) не види себя как мальчик

Почему вместо решения задачи нормальным способом предлагают всегда одно и то же: а именно или эти данные заранее рассчитывать и хранить в отдельном месте (в регистре сведений, реквизите или еще где-то где угодно) или забить и понять что тебе это не надо :-)
Это профессионально 1С-овская особенность или что? Может такой вид троллинга ?

(14) ты так говоришь, как будто знаешь нормальный способ

(14) "отчет с ОДНОЙ колонкой " .  Если БД под скульным движком - напишите вьюху в три строки и дайте пользователю через Excel .

А если к (0) , то очевидно когда прикладной движок позиционируется под разные СУБД - то будет соблюден минимум ANSI SQL- 92. Все остальное это  СКД с общими подходами независимо от СУБД.

Я не могу поверить, что соединения строк с числом в виде строки и датой в виде строки нельзя сделать в запросе.
У меня это в голове не укладывается.
Примерно как если вдруг будет написано что в ладе калине для поворота налево руль надо крутить направо, а для поворота направо нажимать газ и тормоз одновременно, ехать вперед нельзя в-принципе, а для езды назад надо быстро раскачивать руль вправо влево. То есть да, Лада-калина гав-но а не машина, но всё же у неё на самом деле не всё так ужасно, есть недостатки, но в целом всё как у любой машины.
Приведение числа в строку - это не какая-то специфичная или сложная вещь, это не вьюхи там, которые в разных бд по разному себя ведут (в некоторых бд через вьюхи и апдейты делать можно, в некоторых нельзя).... Но преобразовать то число в строку - это ж как-то наверно можно всё таки!!!! Должен быть способ нормальный!

(18) Я тебе уже ответил в (1)

ДенисЧ - Вы ТРОЛЛЬ.

(18) Если есть время (я этото не делал). Решите преобразование через СКД и сделайте трассу в профайлере сего действа . Если увидим мелькание в скуле полного casta -значит не все так плохо. Если нет - значитца все лопатит сервер приложений.

(20) Нет. Я реалист.
Если ты хочешь использовать средства SQL в запросах - это тебе надо использовать более другие инструменты, чем 1с.
Это аксиома.

Этак ты через полгода и UDF захочешь, и хранимки, и свои индексы создавать...

(22) Да и сейчас по быстряку и row_number и led и  lag и индексы выручают.

Если мы говорим об отчетности в принципе из 1С - она может строится (любая отчетность) не средствами 1С .

(0) Чем тебе СКД не устраивает? Там это можно сделать

(25) ну он написал же в (4)

ТС а ты че хочешь то? тебе же написали, "в 1с это не реализовано", ты плачешься? возмущаешься?

(27) Да просто это не обосновано технически - ведь все sql-сервера поддерживают каст. И достаточно было всего лишь передать эту директиву на sql-сервер "как есть" - и написать в инструкции отписку "результат преобразования числа в строку зависит от СУБД".

(28) А файловый движок 1с поддерживает этот каст?

(29) Наличие файлового движка - позор 1с. Могли бы любой из бесплатных sql-серверов прикрутить с поддержкой локальной базы.

(30) Зачем?

(31) Для сокращения велосипедостроения и уменьшения ошибок

(32) То есть вместо своих ошибок править чужие? А им это надо?

(33) В любом случае они этим занимаются - патчат дб2,постгрес.

(34) И что из этого выходит? Всё тот же велосипед, только сбоку

ДБ2 и Постргрес 1С не патчит, а убивает их правильные транзакционные блокировки, прикручивая свою кривущую модель транзакций.

Ведь 1С не отказоустойчивая система. Если например в процессе проведения документа будут создаваться новые элементы справочника, и при этом в процессе проведения документа электричество у сервера ВДРУГ пропадет и всё выключится, то... ТО созданные элементы справочников так и будут созданы, они не откатятся, а документ будет не проведен (то есть транзакция будет не завершена) А значит целостность данных платформой 1С ни в коем виде не поддерживается, а постгрес как раз славится тем, что там всё серьезно с целостностью данных, хотя и там есть изъяны, но такие тривиальные вещи как падение электричества при апдейтах там очень хорошо роллбечатся.

(36) Что за *рень ты написал?

(36) "в процессе проведения документа будут создаваться новые элементы справочника" - это кто же у вас таким дебилизмом занимается? Руки им перешейте поближе к голове.

(38) Ты главное, писателям типовых 77 такого не говори ))

можно и без СКД. прописать у документа свое формирование предствления

(39) да, похоже ТС семерочники покусали, что-то он бред несет.

(36) >  ТО созданные элементы справочников так и будут созданы

не будут

Я смотрю вы о чём угодно готовы спорить, лишь бы не раскрывать тайну отсутствия прямого аналога CASTA в запросе 1С и как же всё таки это сделать можно. Может через временные таблицы как-то можно ?

(43) тебе уже ответили. В запросе 1с нет каста.
Если ты хочешь его туда добавить - устройся на работу в 1с и внеси изменения в код платформы.
Нечего троллить.
В документации строго описано что, чего нет. И плакаться на форуме и биться об стены смысла нет.

(43) Разве тебе сразу не ответили: нам очень жаль, но никак нельзя

Если встать на позицию "понять и простить" (она, кстати, здорово выручает на дороге) в этом вопросе, то вот какое объяснение отсутствия CAST() можно было бы обсудить.

Язык запросов - это только часть 1С, отвечающая, в основном, за выборку данных. Для обработки данных предполагается встроенный язык (и другие механизмы типа СКД) платформы.
SQL деления не предполагает. В нем выборка и обработка данных делаются в одних кусках кода. В SQL нет никакого другого языка, а в 1С - есть. Поэтому требование "хочу как в SQL" некорректно.

Сделав деление на язык запросов и встроенный язык, разработчики постарались разделить функциональность, поместив в язык запросов необходимый минимум возможностей.  
Чем меньше возможностей, тем проще реализация файлового движка и трансляция на язык других СУБД, а также меньше вероятность ошибок программирования на языке запросов.
Судя по вопросам на форумах, вопросы типа "почему этот запрос ничего не выдает или выдает не то, что нужно" встречаются чаще других. Хотите добавить преобразование типов, чтобы таких вопросов было бы больше?

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

Можем начать коллекцию с вашей текущей задачи. Попробуйте убедить коллег, что представление вида
Продажа товаров № 333 от 12/12/2012 на сумму 233 руб 13 копеек вам нужно именно в запросе. Что вы с ним там собираетесь делать?

(46) для начала гуид ссылки в запросе получать бы

(47) 100500+

(47) Зачем он нужен?

(47)(48) Да, какой прикладной смысл?

(46) ну судя по тому, что автор 10 лет на форуме, и только сейчас вдруг обнаружил эту проблему, значит эта возможность не сильно востребована.

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

А мне вот очень не хватает вычисляемых параметров в макетах. В семерке же было - почему в восьмерке убрали? Удобно же.

(52) Получение данных и отображение ДОЛЖНЫ быть разнесены.
Это кошерно и халяльно.

(54) Тогда понятие "представления" вообще вне закона получается, ибо оно выдается одновременно с идентификатором ссылки.

(55) шта?

Имеешь ты ссылку на объект в ИБ - ты одновременно имеешь по сути две сущности, GUID и представление. С чего вдруг ТУТ можно совмещать "получение с отображением", а в запросе внезапно нельзя?

(57) Если я имею ссылку на объект - я имею только заполненную области памяти и переменную-ссылку на неё.
А вот если вдруг я захочу её отобразить - вот тут уже начинаются пляски с отображением.

(52) действительно. ВЫ ведь можете просто использовать ПРЕДСТАВЛЕНИЕ()

(51)  Ну почему . У вас  есть две таблицы . Тип данных колонки в одной строка в другой число . Без танцев - вы их не заджойните .

+(60) Патамуштааа ответ - а вы это ... того самое неправильно спроектировали таблицу :)

Хотя тоже Представление()  как вариант .

(60) А зачем джойнить строку с числом?

(63) :) Действительно. Ну представь что заниматься нормализацией нет времени да и никому это не надо.

И расходы на это мероприятие больше чем прилепить преобразование в запросе.

(64) Вот ты и ответил на вопрос в (0) - "никому это не надо"

(66) А результат то нужен . А как вы его получите "никому это не надо". Главное быстро и несложно . Скорее так.

Без вот этого "а это неправильно и в документации четко написано штаааааааа" :)

(0) >Просто это настолько ну распространенная операция для обычного SQL, что я не могу поверить в то, что нет возможности это сделать в запросе на 1С

А кто-то обещал, что 1С должна поддерживать все, что есть в SQL? Нет.

1С еще столько всего полезного не поддерживает, что поддерживает SQL, а ты придрался к какому-то CAST.

Хотя, если честно, я был бы не против, штука иногда полезная. Но только иногда.

(46) Я думаю объяснение куда банальнее. CAST нам не дали, как обезьяне не дают гранату. Чтобы студенты не косячили и не делали сабж в другом смысле: не соединяли таблицы по число = строка. Или еще хуже, строка = ссылка. А ведь такие попытки мы тут регулярно наблюдаем в примерах г...кода. Не в запросах, так в 1С-ном коде.

Автор не согласен на набор данных (объект) в СКД и перехват события ПриКомпоновкеРезультата ?

Вот мне если честно пофиг, что этого нет в запросах. Хотя иногда и хочется.

Что касается конкретно задачи, озвученной в (0), то не слишком понятно, почему автор считает это извращением. Решается просто:

В запросе выбираем поля:

1. Представление документа
2. " на сумму "
3. рубли (целое количество)
4. " рублей "
5. сумму копеек
6. " копеек "

в настройках СКД группируем этим поля и указываем способ выпода "вместе"

может получиться не так красиво, как хочет автор, но это работает. Ну или перехватывать событие при компоновке и генерировать свою строку.