![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
проблема TADOQuery + MSAccess + Union [D7, MS Access]
vidiv © (2006-12-30 10:05:00)Вобщем работаю с базой данных 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 символов.
Как с этим бороться?
Anatoly Podgoretsky (2006-12-31 11:59:00) [1]> vidiv (31.12.2006 3:47:09) [9]
А нечего говорить потом.
vidiv (2006-12-31 03:47:00) [2]
> Anatoly Podgoretsky © (30.12.06 17:24) [6]
> > vidiv (30.12.2006 10:05:00) [0]
>
> in заменить на =
это частный случай, в полном должнобыть: id IN (2,8,9) и так далее
sniknik (2006-12-30 17:27:00) [3]а вот описанной ситуации с конвертацией блоба в стринг/бинари 255, быть не должно.
sniknik (2006-12-30 17:25:00) [4]> по идее ничего не особенного я не упростил...
а ты попробуй, и именно так как приводишь, не меняя ни одной буквы
> (SELECT image FROM brand WHERE id IN (2)) UNION
> (SELECT image FROM item1 WHERE id IN (45))
2 ошибки последовательно должно выдать, одну после исправления другой.
Anatoly Podgoretsky (2006-12-30 17:24:00) [5]> vidiv (30.12.2006 10:05:00) [0]
in заменить на =
vidiv (2006-12-30 17:09:00) [6]в реальном запросе обединены 4 запроса с одинаковыми типами полей, с использованием алиасов, и еще пару параметров извлекается... по идее ничего не особенного я не упростил...
> ALL "говорит", что не нужно делать отбор уникальных значений
> из запросов в обьеденении...
я это уже прочитал в хелпе =)
sniknik (2006-12-30 13:35:00) [7]> Недокументированная фича ALL :(
ALL "говорит", что не нужно делать отбор уникальных значений из запросов в обьеденении... а т.к. если делать то это влечет за собой не явную сортировку(индекс)/группировку по выбранному полю, чего для мемо и обьектных полей делать нельзя... с ALL же обьеденяется as is без всякой обработки (если конечно нет других факторов, например разные типы у полей в обьеденяемых запросах... что повлечет за собой, если это возможно, неявное преобразование типов во вторичных запросах).
непонятно только почему он у тебя хоть чтото выдавал пусть и с ошибочным значением...
должно было просто давать ошибку.
одно из двух,
либо показанный запрос не соответствует действительности, в реальном есть еще чтото (преобразование типа например), и что подтверждается еще одним "глюком" запросов использованием зарезервированного слова без всяких предосторожностей (еще одну ошибку должно давать. т.е. показанные запросы полностью нерабочие),
либо я не знаю чего...
Savek (2006-12-30 13:00:00) [8]Возможно это и помогло тебе, но предикат ALL предназначен для других целей
vidiv (2006-12-30 10:46:00) [9]Нашел решение сам.
(SELECT image FROM brand WHERE id IN (2)) UNION ALL
(SELECT image FROM item1 WHERE id IN (45))
Недокументированная фича ALL :(
vidiv (2006-12-30 10:09:00) [10]Практика показала, что сам Access возвращает такое значение при таком запросе => ADO, Delphi и конструкция приложения тут не причем, нужно изменить какимто образом запрос. Ктонибудь сталкивался?