wing

ssa

wing
к тому же проблема уже найдена и ликвидирована.

А мы так и останемся в неведении?

Почему же? Я уже отписался:

wing

PaulWist
Пробуй такой код

Спасибо! Помогло! ... всему виной были квадратные скобки ...

Которые?

ssa
И все это подтверждается SYS(3054)?

Серёг, если тестируют под провайдером, то sys(3054) под ним не работает.

ssa

wing

ssa

wing
к тому же проблема уже найдена и ликвидирована.

А мы так и останемся в неведении?

Почему же? Я уже отписался:

wing

PaulWist
Пробуй такой код

Спасибо! Помогло! ... всему виной были квадратные скобки ...

Которые?

Которыми были обрамлены параметры.

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

wing
про SYS(3054) я не в курсе ... к тому же работа ведется не в фоксе, а только с использованием его драйвера.

А что, они уже друг друга стали отменять?

ssa

wing
про SYS(3054) я не в курсе ... к тому же работа ведется не в фоксе, а только с использованием его драйвера.

А что, они уже друг друга стали отменять?

Честно говоря, просто не представляю, как именно его в этом случае включить...

Какие индексы есть на таблицы 1SJourn, dh179

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

2 wing
1) Версия VFP OLEDB провайдера? Должна быть как минимум из 9-й серии! Лучше если патченная (аналогичная той что в VFP9 SP2).
2) Вынести подзапрос из JOIN ... ON в WHERE - где он собственно говоря и будет работать (на логике отбора это никак не скажется)
т.е. примерно так:
Вот тогда уже можно будет начинать думать про оптимизацию и прочие вещи
Кстати, я не в курсе - какая кодовая страница у 1С-овских dbf-ок? какие у них индексы (cdx понимаемый VFP или что-то своё)? От этого во многом зависит степень оптимальности работы запросов через VFP OLE DB провайдер.

Igor Korolyov
Кстати, я не в курсе - какая кодовая страница у 1С-овских dbf-ок?

С 21 билда вроде сделали по-нормальному, 1251. До того в заголовке был бардак.

Цитата:

какие у них индексы (cdx понимаемый VFP или что-то своё)?

Прекрасно понимаемый.

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

Верно. и эти тормоза в итоге становятся неприемлимыми

Igor Korolyov
2 wing
1) Версия VFP OLEDB провайдера? Должна быть как минимум из 9-й серии! Лучше если патченная (аналогичная той что в VFP9 SP2).

у меня 9.0.0.3504 ... а какая в VFP9 SP2?

Igor Korolyov
2) Вынести подзапрос из JOIN ... ON в WHERE - где он собственно говоря и будет работать (на логике отбора это никак не скажется)
т.е. примерно так:

...
INNER JOIN 1SJourn as Жур1
        ON Жур1.IDDoc = Док1.IDDoc 
     WHERE Сотр.isMark = '' AND
           Сотр.isFolder = 2 AND
           Жур1.Date = (  
  SELECT MAX(Жур0.Date)  
    FROM 1SJourn as Жур0, dh179 as Док0  
    WHERE Жур0.IDDocDef = '  4Z'  
      AND Жур0.Date < Жур.Date  
      AND Жур0.IDDoc = Док0.IDDoc  
      AND Док0.sp171 = Док.sp171  
    ) .... 

Вот тогда уже можно будет начинать думать про оптимизацию и прочие вещи
Кстати, я не в курсе - какая кодовая страница у 1С-овских dbf-ок? какие у них индексы (cdx понимаемый VFP или что-то своё)? От этого во многом зависит степень оптимальности работы запросов через VFP OLE DB провайдер.

Я не в курсе, как реализован SQL в VFP ... привык, что на скорость не влияет расположение условий - WHERE или ON JOIN'а ... если влияет - то можно перенести.

Последний провайдер берём тут www.microsoft.com
Его версия (dll-ки) 9.0.0.5815

Что касается твоего запроса, то дело не в скорости, а в том что нельзя в ON использовать подзапросы - а вот в WHERE можно. Т.е. я просто привёл его к синтаксически корректному виду (для фоксового диалекта SQL) Что каксается оптимальности - то возможно более оптимальным будет "перефразировать" запрос - не проверка в WHERE с подзапросом, а подзапрос с группировкой во FROM и соединение с ним (т.е. подзапрос выбирает максимальную дату для ВСЕХ документов или кто там это, а потом идёт join по обеим полям - этой самой максимальной дате и коду кокумента)... Ну думаю что идея понятна. VFP9 уже умеет подзапросы во FROM разбирать.