Не работает прямой запрос в DBF базе.
 

Привожу текст запроса, который возвращает правильный результат в базе SQL:

ТекстЗапроса="SELECT
СпрК.ID as [Контейнер $Справочник.Контейнера]
,$СпрК.ОбъектРодитель as [Релиз $Справочник.Релизы]
FROM
$Справочник.Контейнера as СпрК
INNER JOIN
$Справочник.Релизы as СпрР on $СпрК.ОбъектРодитель=СпрР.ID AND $СпрР.НомерГТД=:ТекущаяГТД";

При выполнении его в базе DBF той-же конфигурации возвращает пустую таблицу. В чем может быть причина? Текст , вроде-бы, должен подходить и для DBF.

ТекущаяГТД - это строка. $СпрР.НомерГТД - то же самое (длина совпадает). $СпрК.ОбъектРодитель - это реквизит справочника $Справочник.Контейнера типа Справочник.Релизы.

Строка соединения:

Соединение = "Provider=VFPOLEDB.1;Data Source=" + КаталогИБ()+ ";Mode=ReadWrite;Extended Properties="";User ID="";Password="";Mask Password=False;Collating Sequence=RUSSIAN;DSN=""";

[quote=romval;42798652]...
ТекущаяГТД - это строка. $СпрР.НомерГТД - то же самое (длина совпадает)...[/quote]
Отсюда поподробнее, что значит длина совпадает.

Попробуй передавать ТекущаяГТД не через параметр, а вставить непосредственно в текст запроса:
"... AND $СпрР.НомерГТД= '"+ТекущаяГТД+"'";

Добрый день!
1 - Длина совпадает - это значит, что длина строки ТекущаяГТД равна длине строки $СпрР.НомерГТД (в начале и в конце могут быть лидирующие и концевые пробелы).

Попробывал. То-же самое. Ничего не изменилось.

Похоже, проблема тут в том, что в SQL базе колонка "Релиз" возвращаемой запросом таблицы значений заполнена, а в DBF базе - нет( $СпрК.ОбъектРодитель имеет пустое значение). Почему?

Я убрал конструкцию INNER JOIN из этого запроса - и у меня именно так и получилось - колонка Релиз возвращаемой таблицы значений не заполнена.

что за ОбъектРодитель? может PARENTEXT?

Да нет. Это просто так реквизит справочника Контейнеры назван. Он имеет тип "Справочник.Релизы". Ничего особенного здесь нет.

Справочник Контейнеры НЕ ПОДЧИНЕН справочнику Релизы.

а в самом дбф файле справочника Контейнеры все данные есть? на дбф базах я работал с 1sqlite

Разбей запрос на части и отдельно посмотри что будет.
Например, 1 - просто запрос к контейнерам, 3 - просто к релизам, 3 - к релизам с ГТД и т.д. Займет 15 минут

может база полетела. может платформа не та. может индексы или кодировка не та. может версия 1с++ не та.
свой вариант?

(9)декомпозиция запроса легко поможет все выяснить. Запрос то тривиальный, было бы о чем вести речь.

7 - Уже говорил - повторю. ОДНА И ТА ЖЕ база с одними и теми же данными развернута в DBF формате и в SQL формате. В SQL релизы на месте, а в DBF - пусто.

8 - Уже разбил - смотри 3.

9 - Стандартный (не прямой) запрос делаю - все данные на месте (и релизы тоже).

10 - Проще не придумаешь. Сейчас попробую вытянуть отдельно колонку "ОбъектРодитель." Думаю, что будет колонка с пустыми значениями в DBF. В SQL - заполненная колонка.

10 - Так и есть. Выполнил такой запрос:

ТекстЗапроса="SELECT
| $СпрК.ОбъектРодитель as [Релиз $Справочник.Релизы]
|FROM
| $Справочник.Контейнера as СпрК";

Результат - в SQL - длинная заполненная колонка, в DBF - длинная пустая колонка. Сейчас попробую сделать INNER JOIN этого запроса со справочником Релизы и релизы вытянуть оттуда.

поле справочника не может быть в SQL базе заполнено, а той же dbf базе не заполнено. Значит что-то нам не договариваете. Смотрите, что в физических таблицах. Сходили в словарь (dd или dds), узнали имена полей, таблиц в QA простым запросом к таблице select * смотрите в чем дело. В DBF базе вьюером или VFP тоже самое. Чудес не бывает. Отличия в dbf и SQL есть, но не на уровне заполненности поля справочника. Может и вправду кодировка. Это не бином Ньютона, надо препарировать таблицу на физическом уровне

Вообще в результирующей таблице нет ни одной строки.Делаю в SQL - данные есть.

(12)Вы не типизируйте колонку запроса, пусть выводится как есть, уберите Ваше AS $Справочник...

ТекстЗапроса="SELECT
| $СпрК.ОбъектРодитель AS Релмз
|FROM
| $Справочник.Контейнера as СпрК";

Так надо смотреть что там хранится

13 - Даже не знаю что Вам еще сказать. Может быть пагубно влияет на DBF тот факт, что длина Наименования элемента справочника Релизы равна 0 (нулю). Может быть в этом вся проблема зарыта?

Спасибо. Буду рыть дальше.

ну так Вы колонку типизируете, а отобразить ее непонятно как. Уберите типизацию и рыть не придется

Такой запрос "SELECT SP1294 FROM SC1281" - результат тот-же.

(19)что значит тот же? пустая колонка ? а в SQL что выводится ?

что-то Вы темните. Реквизит случайно не периодический ?

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

основное представление элементов справочника "Релизы" в виде кода указано?
номер релиза - код или строковый реквизит элемента справочника "Релизы"?

походу код. значит надо напрямую к нему обращаться. наверное.

20 - это значит: в DBF - пустая колонка (колонка, заполненная пустыми значениями) ,а в SQL - заполненная непустыми значениями.

21,22 - нет, реквизит непериодический.

23 - да, в виде кода. Тип кода - текстовый. Номер релиза (он же код) - строка 12 символов.

24 - не понял? Что значит "значит надо напрямую к нему обращаться"?

24 -Сейчас попробую.

Я что-то уже потерял нить рассуждений. Если нетипизированная (внутренне содержание) колонка пустая. то надо смотреть почему В чем отличие двух баз, это явно не одна и та же база в разных форматах хранения

Пришли на почту базу dbf или таблицу эти две таблицы и словарь

28-USSR > Извините, не подскажите - как здесь прикрепить к сообщению электронной почты файлы?

(29)Не знаю )

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

Работать с ним примерно так:

оСпрНаборовРефЗн = СоздатьОбъект("ЗапросКСправочнику");
оСпрНаборовРефЗн.Инит("НаборыРеференсныхЗначений");
оСпрНаборовРефЗн.ДобавитьРеквизиты("ТекущийЭлемент,Наименование");
оСпрНаборовРефЗн.ДобавитьУсловиеПоСписку("Аппарат", глОбщийОбъектМетоды.СписокЗначенийУник(ПолучитьПустоеЗначение("Справочник.Аппараты"), Аппарат));
оСпрНаборовРефЗн.ДобавитьУсловиеПоСписку("СпрНабРефЗн.Номенклатура", спНоменклатуры);
оСпрНаборовРефЗн.ДобавитьСоединение("СпрНабРефЗн", "НаборыРеференсныхЗначений", "СпрНабРефЗн.ТекущийЭлемент", "Родитель");
тзНаборовРефЗн = оСпрНаборовРефЗн.ВыполнитьЗапрос();

тзНаборовРефЗн.ВыбратьСтроки();
Пока тзНаборовРефЗн.ПолучитьСтроку() = 1 Цикл
глСпДобавитьЗначение(спНаборовРефЗн, тзНаборовРефЗн.ТекущийЭлемент, тзНаборовРефЗн.Наименование);
КонецЦикла;

Переделок с использования классического объекта 1С "Справочник" немного. Работает очень быстро. До 10000 запросов в секунду на DBF варианте. Использует 1SQLite Орефкова для DBF и прямой доступ от 1С++ для SQL. Соответственно в монопольном доступе тоже работает.

Ну и по поводу самой ошибки. Может посмотреть что будет возвращать классический Запрос?

(31)Тут примитивный почти скалярный запрос не работает, а Вы класс предлагаете. Надо с одной таблицей разобраться. 1С++ прекрасно работает и для DBF. Поэтому если проведение не не прямых запросах, то монопольный режим не такое уж и ограничение. Зато отличий между dbf и sql куда меньше, чем между синтаксисами 1с++ и sqllile. А классический запрос тут даром не нужен, надо посмотреть прямым без типизации полей

(32) Я намекаю, что если есть необходимость работать с SQL и DBF, то желательно всю рутину отличий одного варианта от другого вынести в какую-либо надстройку. У меня, например, вся конфигурация переписана на мой ЗапросКСправочнику. Там же где нужно обращение к документам и регистрам используется ПрямойЗапрос. Поэтому ошибок связанных с отличием SQL от DBF практически нет. Все оттестировано давным давно.

(33)Это все правильно и хорошо ) Только в обсуждаемом запросе отличий в запросе в зависимости от формата хранения нет вообще ) Синтаксис идентичен.