orefkov писал(а) 03. Июня 2010 :: 20:20:


Решение хорошее, одно "но", я так понял что у Billа текущей строкой является row_id (по крайней мере по данному коду судил ТП.ТекущаяСтрока = -1). У меня является id типизированное к значению справочника. Уж точно счас не помню, но вроде и присваивать ему надо типизированный элемент. Это в принципе не страшно, я могу row_id включить в список обязательных колонок, id пускай будет "ПустойИД" и аналогично понимать что идет редактирование.
Я в голове обдумываю реализацию до конца, просто на неделе зарекся 7-кой не заниматься ибо снеговик на бок валится из-за этого.

Пы.сы. добавил в свой список изменений в новой версии. Да уж прилично накопилось, думаю надо уже заканчивать, а то так никогда он не выйдет. 

vandalsvq писал(а) 04. Июня 2010 :: 03:22:

В тексте запроса для поставщика sql-параметры обозначаются как @ИмяПараметра, далее смотрим доку:

Объект SQLiteDataProvider :: УстановитьПараметр / SetParam

Синтаксис: УстановитьПараметр(ИмяПараметра, Значение, [Модификатор])

Параметры:
ИмяПараметра - тип: Строка. Название именнованого sql-параметра.
Значение - тип: Любой. Устанавливаемое значение параметра.
Модификатор - тип: Число. Модификатор, задающий правило преобразования значения 1С в значение базы данных. Подробнее см. Преобразование значений 1С в значения базы данных (работа с параметрами). Необязательный параметр. По умолчанию 0.
Возвращает: нет.

Описание: Аналогично SQLiteQuery::УстановитьПараметр.

SQL-параметры можно устанавливать в любое время, поставщик хранит их и по мере надобности применяет к текущему выполняемому запросу.


Вот пример для поставщика, отображающего доки по графе отбора Контрагент:

Процедура Создать()
	Пост=СоздатьОбъект("SQLiteDataProvider");
	Пост.УстановитьБД();

	Пост.УстановитьТекстЗапроса("
	|SELECT
	|О.idx_MDID_PARENTVAL_CHILDDATE_CHILDTIME_CHILDID [key]
	|,Ж.iddoc [Док :Документ]
	|,Ж.iddocdef [Док_вид :ВидДокументаПредставление]
	|,Ж.DocNo Номер
	|,Ж.date [Дата :Дата]
	|,Ж.time [Время :Время]
	|,О.ParentVal [Контрагент :Неопределенный]
	|FROM __1S_Crdoc О inner join Журнал Ж
	|  ON О.ChildID=Ж.IdDoc
	|WHERE
	|О.MdID=:ГрафаОтбора.Контрагент and О.parentval = @Клиент
	|and О.childdate BETWEEN @НачДата AND @КонДата
	|", "key", "Док");

	Пост.УстановитьПараметр("@Клиент", выбКлиент, -1);
	Пост.УстановитьПараметр("@НачДата", НачДата);
	Пост.УстановитьПараметр("@КонДата", КонДата);

	ДобавитьКолонку("Док_вид", "Документ");
	ДобавитьКолонку("Дата");
	ДобавитьКолонку("Время");
	ДобавитьКолонку("Номер");
	ДобавитьКолонку("Контрагент");

	_ТП.ПоставщикДанных=Пост;
КонецПроцедуры

Процедура ПриСменеУсловий()
	Пост = _ТП.ПоставщикДанных;
	Пост.УстановитьПараметр("@Клиент", выбКлиент, -1);
	Пост.УстановитьПараметр("@НачДата", НачДата);
	Пост.УстановитьПараметр("@КонДата", КонДата);
	Пост.Перечитать();
	//_ТП.ПоставщикДанных = "";
	//_ТП.ПоставщикДанных = Пост;
КонецПроцедуры

 

Цитата:

Я думаю, что ничего страшного не будет, если в id новой строки будет ПустойИД. Ну оттипизируется он как пустое значение типа и вида текущего справочника. Все равно на время ввода новой строки этот id не нужен.
Встанет другой вопрос, как сделать так, что бы новая строка на время редактирования всегда была последней, независимо от ключа порядка. Тут наверное нужно будет добавлять дополнительное поле в запрос. Для новой строки это поле равно 1, а для всех остальных строк 0. И всегда это поле добавлять первым в ключ порядка.

Bill писал(а) 04. Июня 2010 :: 08:24:

Собственно в ключ порядка я бы не лез. Он у меня для SQL составлен с точностью как 1С строит индексы (даже порядок полей соблюден, в dds постоянно смотрел когда делал).
Можно для таких полей в union-е добавить максимально-возможные значения.
Но имхо не это вопрос, а вопрос в том как вообще этот union all добавить?

Bill, т.е. хочешь сказать что ODBC съедает такой запрос?

select <поля запроса>
from Справочник.Контрагенты as sc13
where parentid = '     0   '
union all
select <пустые поля>
where 0=0 

* ушел проверять

Цитата:


Только не забудь в первом Selecte всем полям алиасы назначить, а не только idx_ID, иначе может ругаться.
И набор и порядок полей в обои селектах должен быть одинаковый (ну это ты знаешь).

vandalsvq писал(а) 04. Июня 2010 :: 09:11:

Можно и так. Только если во время редактирования одинэсина вдруг упадет, мусор останется.

Странно, что в dbf не пролазит конструкция 0=1.
В скуле нормально работает. Я даже частенько при динамическом построении запроса специально пишу WHERE 1=1, чтобы потом при добавлении условий не париться с тем, какое слово писать WHERE или AND.

Цитата:


А с SQL какие проблемы?