Uzhast
Цитата:

Я думаю, что врядли кто-то, кто использует ТП, переопределяет названия колонок вручную. Т.е. ИМХО лучше один раз определить названия колонок в тексте запроса и больше не париться с настройкой соответствия между номером колонки и её названием.

Ещё вопрос:
Я так понимая, что конструкция вида:

WHERE _Поле-Ключ_ IN (%СписокИД%) 

обязательна всегда (или это тожк только "пока"?), так почему бы не сделать её невидимой для пользователя этого провайдера. Т.е. чтобы эта строка автоматом добавлялась при выполнении запроса. Поправьте меня, если я не прав или чего-то не понимаю.

По-моему GROUP BY не сильно рекомендуется (а точнее сильно не рекомендуется) в запросах провайдера ТП под ODBC. Тогда может и здесь тоже сделать такое жёсткое ограничение. Или ты хочешь создать вообще что-то уневерсальное и оч. сладкое? 

spock писал(а) 26. Октября 2007 :: 18:07:

Хм. Чуда не случилось. Похоже, этот провайдер так же тупит с TOP. Такой запрос:

SELECT TOP 1
 IDDocDef + IDDoc AS [Документ $Документ]
FROM
 [1sjourn]
ORDER BY IDDoc 

выполняется отнюдь не мгновенно - с большим количеством дисковых операций А xBase оно, похоже, не поддерживает. Значит, изврат с TOP не исправим...

kiruha писал(а) 29. Октября 2007 :: 09:07:

Поздравляю

PS. Но, вообще, VFP и Advantage на справочниках тоже довольно быстро работают. Лучше тестить на журналах документов.

С GROUP BY извращаться можно, но не до такой степени Тут есть рамки: "Главное, чтобы в результате количество строк соответствовало количеству ИДшников и на каждый ИДшник была соответствующая ему строка."

Пример корректного использования GROUP BY. Допустим, у нас есть нечто вроде регистра "Остатки товаров" с измерениями: "Товар", "Статус". "Статус" принимает два значения: "На складе" и "В пути". Есть также ресурс "Количество". Допустим, нужно отобразить справочник "Номенклатура" и по каждой позиции вывести остаток на складе+в пути. Для этого можно использовать примерно такой запрос:

SELECT
 Товары.ID AS [Товар $Справочник.Номенклатура],
 SUM ($Остатки.Количество) AS Остаток
FROM
 $Справочник.Номенклатура AS Товары
LEFT JOIN $РегистрИтоги.ОстаткиТоваров AS Остатки ON ФильтрПоПериоду AND $Остатки.Товар = Товары.ID
WHERE
 Товары.ID IN (%СписокИД%)
GROUP BY
 Товары.ID
 

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

Небольшое обновление провайдера:

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

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

- Теперь у нас два ключевых поля: "КлючевоеПолеОпорнойТаблицы" - это ID или IDDoc. И "КлючевоеПолеЗапроса" - это название колонки, которая будет содержать значение, идентифицирующее строку запроса (например "Документ", "Клиент" и т.д.). Оно должно получаться с участием поля ID или IDDoc - чтобы была возможность из ключевого поля получить сырой ID или IDDoc.

- Переделана тестовая обработка: добавлены "наборы настроек". Набор настроек позволяет быстро заполнить поля "Текст запроса", "Опорная таблица", "Тег индекса", фильтры. Наборы настроек бывают следующих видов:

 - "Журнал.Полный" - все документы в системе
 - "Журнал.ВидЖурнала" - документы указанного журнала
 - "Документ.ВидДокумента" - документы данного вида
 - "Справочник.ВидСправочника" - отобразить справочник с отключенной иерархией
 - "Справочник.ВидСправочника - фильтр по группе" - отобразить только те элементы справочника, которые принадлежат выбранной группе.

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

- Изменен файл "QueryRows.prg". Убран цикл перебора полей, что заметно ускорило работу провайдера. Также внесены некоторые упрощения и добавлены фильтры. ВНИМАНИЕ! Если вы уже тестировали провайдер и у вас в базе уже есть "QueryRows.prg", то этот файл не только нужно заменить на новый, но и еще требуется удалить файл "QueryRows.fxp". Это скомпилированный вариант "QueryRows.prg". Фокс будет использовать его, даже если prg-файл был изменен. Если в базе также есть "QueryRows.err", то его тоже желательно удалить.

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

Брать провайдер можно там же:
http://uzhast.fatal.ru/vfp.oledb.provider/
http://uzhast.fromru.su/vfp.oledb.provider/

Думаю, от необходимости использовать WHERE ID IN (%СписокИД%) уйти не удасться. В запросе ведь можно использовать джойны с подзапросами. Например:
SELECT
ID AS [Товар $Справочник.Номенклатура]
LEFT JOIN (
... запрос по остаткам
) AS Остатки ON Остатки.Товар = ID

А я очень сомневаюсь, что фокс догадается применить фильтр по ID ко вложенному запросу. Поэтому, скорее всего, и во вложенном запросе понадобится указывать WHERE $Остатки.Товар IN (%СписокИД%).

Теперь по поводу фильтров. Фильтр должен задаваться в том виде, какой получается после вычисления индексного выражения. Например, вот так выглядит фильтр для некоторого журнала документов, начиная с даты 1 ноября 2007 г.: "  1S20071101". Т.е. сначала 4 символа - ИД журнала, затем дата в виде ГГГГММДД. Аналогично для видов документов, только вместо ИД журнала идет ИД вида документов.

Думаю, что в дальнейшем для значений фильтров можно будет использовать метапарсер. Например, в таком виде: "$ЖурналДокументов.Банковские:ДатаНачала". Правда, пока не проверял, корректно ли он будет отрабатывать подобные выражения: без пробелов... Хотя, по идее, можно будет и дострогать, если что...

Для справочников, если мы, например, хотим поставить фильтр по первым буквам наименования, то нужно использовать строку с прописными буквами. Потому что, индексное выражение для тега Descr выглядит как UPPER (Descr). Кстати, штатные гриды фильтровать по первым буквам наименования не умеют Примеры фильтров:
- для тега "Descr" (упорядочивание по наименованию): "БАНК". Выбрать все элементы, которые начинаются на "банк".
- для тега "PDescr" (фильтр по группе справочника + упорядочивание по наименованию): "   1LO   2ЗАО": 9 символов ИД группы, затем значение поля IsFolder (2), затем первые буквы наименования ("ЗАО"). Таким образом мы отбираем все элементы одной группы, которые начинаются на "ЗАО".