Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2007.03.25;
Скачать: CL | DM;

Вниз

проблема TADOQuery + MSAccess + Union   Найти похожие ветки 

 
vidiv ©   (2006-12-30 10:05) [0]

Вобщем работаю с базой данных MSAccess через компоненты ADO. Проблема возникает при работе с компонентов TADOQuery.

При таком запросе:
SELECT image FROM brand WHERE id IN (2)
компонент передает правильное значение для поля image, а при таком запросе:
(SELECT image FROM brand WHERE id IN (2)) UNION
(SELECT image FROM item1 WHERE id IN (45))

обрезает значение поля image, таким образом, что бы оно уместилось в 255 символов.

Как с этим бороться?


 
vidiv ©   (2006-12-30 10:09) [1]

Практика показала, что сам Access возвращает такое значение при таком запросе => ADO, Delphi и конструкция приложения тут не причем, нужно изменить какимто образом запрос. Ктонибудь сталкивался?


 
vidiv ©   (2006-12-30 10:46) [2]

Нашел решение сам.

(SELECT image FROM brand WHERE id IN (2)) UNION ALL
(SELECT image FROM item1 WHERE id IN (45))


Недокументированная фича ALL :(


 
Savek   (2006-12-30 13:00) [3]

Возможно это и помогло тебе, но предикат ALL предназначен для других целей


 
sniknik ©   (2006-12-30 13:35) [4]

> Недокументированная фича ALL :(
ALL "говорит", что не нужно делать отбор уникальных значений из запросов в обьеденении... а т.к. если делать то это влечет за собой не явную сортировку(индекс)/группировку по выбранному полю, чего для мемо и обьектных полей делать нельзя... с ALL же обьеденяется as is без всякой обработки (если конечно нет других факторов, например разные типы у полей в обьеденяемых запросах... что повлечет за собой, если это возможно, неявное преобразование типов во вторичных запросах).

непонятно только почему он у тебя хоть чтото выдавал пусть и с ошибочным значением...
должно было просто давать ошибку.
одно из двух,
либо показанный запрос не соответствует действительности, в реальном есть еще чтото (преобразование типа например), и что подтверждается еще одним "глюком" запросов использованием зарезервированного слова без всяких предосторожностей (еще одну ошибку должно давать. т.е. показанные запросы полностью нерабочие),
либо я не знаю чего...


 
vidiv ©   (2006-12-30 17:09) [5]

в реальном запросе обединены 4 запроса с одинаковыми типами полей, с использованием алиасов, и еще пару параметров извлекается... по идее ничего не особенного я не упростил...


> ALL "говорит", что не нужно делать отбор уникальных значений
> из запросов в обьеденении...

я это уже прочитал в хелпе =)


 
Anatoly Podgoretsky ©   (2006-12-30 17:24) [6]

> vidiv  (30.12.2006 10:05:00)  [0]

in заменить на =


 
sniknik ©   (2006-12-30 17:25) [7]

> по идее ничего не особенного я не упростил...
а ты попробуй, и именно так как приводишь, не меняя ни одной буквы
> (SELECT image FROM brand WHERE id IN (2)) UNION
> (SELECT image FROM item1 WHERE id IN (45))
2 ошибки последовательно должно выдать, одну после исправления другой.


 
sniknik ©   (2006-12-30 17:27) [8]

а вот описанной ситуации с конвертацией блоба в стринг/бинари 255, быть не должно.


 
vidiv ©   (2006-12-31 03:47) [9]


> Anatoly Podgoretsky ©   (30.12.06 17:24) [6]
> > vidiv  (30.12.2006 10:05:00)  [0]
>
> in заменить на =

это частный случай, в полном должнобыть: id IN (2,8,9) и так далее


 
Anatoly Podgoretsky ©   (2006-12-31 11:59) [10]

> vidiv  (31.12.2006 3:47:09)  [9]

А нечего говорить потом.



Страницы: 1 вся ветка

Текущий архив: 2007.03.25;
Скачать: CL | DM;

Наверх




Память: 0.49 MB
Время: 0.039 c
2-1172936846
LigthStone
2007-03-03 18:47
2007.03.25
Unicode


15-1172611365
Gero
2007-02-28 00:22
2007.03.25
Лебедев облажался


15-1172460338
Slider007
2007-02-26 06:25
2007.03.25
С днем рождения ! 24 февраля


2-1172973841
arturich
2007-03-04 05:04
2007.03.25
Работа с TProgressBar


2-1173021118
Tru
2007-03-04 18:11
2007.03.25
Enabled