| 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
| Цитата:
Попробуй передавать ТекущаяГТД не через параметр, а вставить непосредственно в текст запроса: "... 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)Это все правильно и хорошо ) Только в обсуждаемом запросе отличий в запросе в зависимости от формата хранения нет вообще ) Синтаксис идентичен. | |
Интернет-форум Краснодарского края и Краснодара |
