alexmyt писал(а) 02. Февраля 2010 :: 08:14:

Чет прогнал тестовый запрос... вроде все верно работает в КОПе. Хм... проверю подробнее.

vandalsvq писал(а) 02. Февраля 2010 :: 09:24:

Вы не посмотрели? Был бы крайне признателен за авторское мнение

Есть предложение:
в функции ПарсингВТПоследнееЗначение смягчить требование к параметру ГраницаЗначения. Н.р. если в нем есть символ ".", то подставлять его "как есть". Получим возможность использовать коррелированный поДзапрос (вроде правильно его обозвал )
н.р. для запросов вида:

|Select
|	...
|	$рнк.Сумма * $ПоследнееЗначение.Валюты.Курс( $рнк.Валюта, $журн.ПозицияДокумента ) AS Сумма
|From ЖурналДокументов AS журн $NoLock
|INNER JOIN Документ.РасходнаяНакладная AS рнк $NoLock ON $рнк.ТекущийДокумент = $журн.ТекущийДокумент
|...
 

вроде нормально работает.

Предложение по LIMIT/TOP. Что если реализовать такой алгоритм:
При парсинге в ДБФ базе удалять из текста запроса TOP N. Если из текста был удален хоть один оператор - проверить, есть ли в тексте подстрока LIMIT. Если нет - выругаться (обратить внимание программиста на необходимость модификации запроса).
То же самое и для sql базы. Пытаемся удалить LIMIT, если удалили хоть один - проверим, есть ли TOP.
В итоге, универсальный запрос будет содержать и TOP, и LIMIT. Запрос, ориентированный только на одну базу - будет работать, при попытке запустить его в другом варианте - будет напоминать о необходимости ручной модификации.

novichek, спасибо за пожелания, на самом деле все по делу, почти . Но давай по порядку...
1. TOP N ..... LIMIT N.
Согласен что вполне нормальный вариант. Но тогда надо подсчет количества удаленных TOP/LIMIT и сравнивать с количеством LIMIT/TOP (обратных выражений). Т.о. можно с большой долей вероятности сказать что "никто не уйдет безнаказанно" .
2. Что касается РегистрОстатки.... хм. Наверное "Нет", не стоит этого делать. Во-первых зачем (если есть ОстаткиОбороты), а во-вторых на самом деле большой принципиальной разницы между 2-я запросами Остатков, или одного ОстаткиОбороты я не вижу. Скорость все равно не увеличится. Хотя если покажешь обратный пример готов забрать все сказанное с собой .
3. Т.е. не зависимо от того был остаток или нет ты хочешь получать строки начальных и конечных остатков. Хм. Тут проблема в реализации. Как правило набор разрезов Остатки <> Обороты. Соответственно когда получаем ВТОстатки мы не получаем желаемые строки с нолями. А ВТОбороты они нужны. В общем красивого и удобного решения в голове пока нет .
4. IsNull/IfNull реализовано, но лежит в закромах родины. Надо бы решить вопросы с БИОбороты и можно выкладывать.
Попробую туда добавить TOP/LIMIT и выложу. Но наврядли раньше начала выходных. Зато ты можешь попробовать реализовать пожелалки 2 и 3. Может что получится, посмотрим-с 

classic писал(а) 11. Февраля 2010 :: 07:50:

В принципе дополнительный парсинг TOP/LIMIT (счас уже один есть такой) не займет много времени. По крайней мере всегда можно доп. опцию ввести. А если я буду регэкспами тащить их то количество в любом случае получу. Другое дело что я буду тащить например только TOP и коцать их, а проверку лимит можно просто через НАЙТИ сделать. Короче когда реализую тогда и посмотрим сколько времени оно съело.

Поскольку мы в ответе за тех кого.... (кому как нравится ), в общем поболеть нормально не вышло, обратились с вопросом, накопали ошибку. Как итог новый релиз... мы ведь за оперативность да?

1.05.008 от 15.02.10 г.
- Исправлена ошибка подстановки предопределенных текстовых параметров с использованием модификаторов для SQL версии БД.

Брать как всегда в топе.

Спасибо
А еще в следующий релиз хорошо бы включить функцию

// ===============================
Функция ПарсингВидДокумента(ТекстЗапроса)
	Если ЭтоSQL = 0 Тогда
		ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "$ВидДокумента.", ":ВидДокумента.");
	КонецЕсли;

	Возврат ТекстЗапроса;
КонецФункции //ПарсингВидДокумента
 

Ну и вызов ее в нужном месте