К списку форумов К списку тем
Регистрация    Правила    Главная форума    Поиск   
Имя: Пароль:
Рекомендовать в новости

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

Гость
0 - 26.08.2016 - 10:49
Привожу текст запроса, который возвращает правильный результат в базе 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=""";



1 - 26.08.2016 - 12:17
Цитата:
Сообщение от romval Посмотреть сообщение
...
ТекущаяГТД - это строка. $СпрР.НомерГТД - то же самое (длина совпадает)...
Отсюда поподробнее, что значит длина совпадает.

Попробуй передавать ТекущаяГТД не через параметр, а вставить непосредственно в текст запроса:
"... AND $СпрР.НомерГТД= '"+ТекущаяГТД+"'";
Гость
2 - 29.08.2016 - 10:21
Добрый день!
1 - Длина совпадает - это значит, что длина строки ТекущаяГТД равна длине строки $СпрР.НомерГТД (в начале и в конце могут быть лидирующие и концевые пробелы).

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

Похоже, проблема тут в том, что в SQL базе колонка "Релиз" возвращаемой запросом таблицы значений заполнена, а в DBF базе - нет( $СпрК.ОбъектРодитель имеет пустое значение). Почему?
Гость
3 - 29.08.2016 - 11:02
Я убрал конструкцию INNER JOIN из этого запроса - и у меня именно так и получилось - колонка Релиз возвращаемой таблицы значений не заполнена.
4 - 29.08.2016 - 11:37
что за ОбъектРодитель? может PARENTEXT?
Гость
5 - 29.08.2016 - 11:56
Да нет. Это просто так реквизит справочника Контейнеры назван. Он имеет тип "Справочник.Релизы". Ничего особенного здесь нет.
Гость
6 - 29.08.2016 - 12:05
Справочник Контейнеры НЕ ПОДЧИНЕН справочнику Релизы.
7 - 29.08.2016 - 17:30
а в самом дбф файле справочника Контейнеры все данные есть? на дбф базах я работал с 1sqlite
8 - 29.08.2016 - 18:34
Разбей запрос на части и отдельно посмотри что будет.
Например, 1 - просто запрос к контейнерам, 3 - просто к релизам, 3 - к релизам с ГТД и т.д. Займет 15 минут
9 - 30.08.2016 - 01:12
может база полетела. может платформа не та. может индексы или кодировка не та. может версия 1с++ не та.
свой вариант?
10 - 30.08.2016 - 11:54
(9)декомпозиция запроса легко поможет все выяснить. Запрос то тривиальный, было бы о чем вести речь.
Гость
11 - 30.08.2016 - 15:34
7 - Уже говорил - повторю. ОДНА И ТА ЖЕ база с одними и теми же данными развернута в DBF формате и в SQL формате. В SQL релизы на месте, а в DBF - пусто.

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

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

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

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

Результат - в SQL - длинная заполненная колонка, в DBF - длинная пустая колонка. Сейчас попробую сделать INNER JOIN этого запроса со справочником Релизы и релизы вытянуть оттуда.
13 - 30.08.2016 - 15:53
поле справочника не может быть в SQL базе заполнено, а той же dbf базе не заполнено. Значит что-то нам не договариваете. Смотрите, что в физических таблицах. Сходили в словарь (dd или dds), узнали имена полей, таблиц в QA простым запросом к таблице select * смотрите в чем дело. В DBF базе вьюером или VFP тоже самое. Чудес не бывает. Отличия в dbf и SQL есть, но не на уровне заполненности поля справочника. Может и вправду кодировка. Это не бином Ньютона, надо препарировать таблицу на физическом уровне
Гость
14 - 30.08.2016 - 15:54
Вообще в результирующей таблице нет ни одной строки.Делаю в SQL - данные есть.
15 - 30.08.2016 - 15:54
(12)Вы не типизируйте колонку запроса, пусть выводится как есть, уберите Ваше AS $Справочник...
16 - 30.08.2016 - 15:56
ТекстЗапроса="SELECT
| $СпрК.ОбъектРодитель AS Релмз
|FROM
| $Справочник.Контейнера as СпрК";

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

Спасибо. Буду рыть дальше.
18 - 30.08.2016 - 16:41
ну так Вы колонку типизируете, а отобразить ее непонятно как. Уберите типизацию и рыть не придется
Гость
19 - 30.08.2016 - 17:05
Такой запрос "SELECT SP1294 FROM SC1281" - результат тот-же.
20 - 30.08.2016 - 17:10
(19)что значит тот же? пустая колонка ? а в SQL что выводится ?
21 - 30.08.2016 - 17:12
что-то Вы темните. Реквизит случайно не периодический ?
22 - 30.08.2016 - 17:17
нет периодическим исключается, там все по другому
23 - 30.08.2016 - 20:05
основное представление элементов справочника "Релизы" в виде кода указано?
номер релиза - код или строковый реквизит элемента справочника "Релизы"?
24 - 30.08.2016 - 20:09
походу код. значит надо напрямую к нему обращаться. наверное.
Гость
25 - 31.08.2016 - 10:52
20 - это значит: в DBF - пустая колонка (колонка, заполненная пустыми значениями) ,а в SQL - заполненная непустыми значениями.

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

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

24 - не понял? Что значит "значит надо напрямую к нему обращаться"?
Гость
26 - 31.08.2016 - 11:33
24 -Сейчас попробую.
27 - 31.08.2016 - 12:25
Я что-то уже потерял нить рассуждений. Если нетипизированная (внутренне содержание) колонка пустая. то надо смотреть почему В чем отличие двух баз, это явно не одна и та же база в разных форматах хранения
28 - 31.08.2016 - 12:29
Пришли на почту базу dbf или таблицу эти две таблицы и словарь
Гость
29 - 31.08.2016 - 14:51
28-USSR > Извините, не подскажите - как здесь прикрепить к сообщению электронной почты файлы?
30 - 31.08.2016 - 15:04
(29)Не знаю )
Гость
31 - 31.08.2016 - 22:08
А не пытались воспользоваться классом ПрямойЗапрос?
Если нужно работать одновременно с SQL и DBF, то он будет поудобнее. Я же реализовал свой класс для работы со справочниками.

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

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

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

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

Ну и по поводу самой ошибки. Может посмотреть что будет возвращать классический Запрос?
32 - 01.09.2016 - 06:08
(31)Тут примитивный почти скалярный запрос не работает, а Вы класс предлагаете. Надо с одной таблицей разобраться. 1С++ прекрасно работает и для DBF. Поэтому если проведение не не прямых запросах, то монопольный режим не такое уж и ограничение. Зато отличий между dbf и sql куда меньше, чем между синтаксисами 1с++ и sqllile. А классический запрос тут даром не нужен, надо посмотреть прямым без типизации полей
Гость
33 - 01.09.2016 - 08:49
(32) Я намекаю, что если есть необходимость работать с SQL и DBF, то желательно всю рутину отличий одного варианта от другого вынести в какую-либо надстройку. У меня, например, вся конфигурация переписана на мой ЗапросКСправочнику. Там же где нужно обращение к документам и регистрам используется ПрямойЗапрос. Поэтому ошибок связанных с отличием SQL от DBF практически нет. Все оттестировано давным давно.
34 - 01.09.2016 - 11:14
(33)Это все правильно и хорошо ) Только в обсуждаемом запросе отличий в запросе в зависимости от формата хранения нет вообще ) Синтаксис идентичен.


К списку вопросов
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск




Copyright ©, Все права защищены