Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Начинающим";
Текущий архив: 2009.07.12;
Скачать: [xml.tar.bz2];

Вниз

Ошибка запроса к dbf.   Найти похожие ветки 

 
MonoLife ©   (2009-05-18 08:02) [0]

Ситуация крайне глупая, но я в недоумении...
Имеются базы dbf (не мои). Произвожу запросы к ней с использованием конструкции в SQL:
SELECT <fields> FROM <base1> WHERE date1 BETWEEN :dt1 and :dt2
UNION SELECT <fields> FROM <base2> WHERE date1 BETWEEN :dt1 and :dt2 ORDER BY <field>

Параметры dt1 и dt2 TDate. Поля date1 - TDate.
Псевдоним в BDE-администраторе настроен на эти dbf файлы.
Компонент TQuery databasename=псевдониму...
Подобный запрос может работать месяц, год... Но в один момент UNION перестает работать:(
По отдельности из обеих баз выборка идет правильная, а с UNION, то 0 записей, то только записи из таблицы, к примеру base2...
Проверка файлов dbf различными другими средствами показывает, что база данных без ошибок...
Я не понимаю, что случается и почему вдруг UNION перестает "работать".
Самое интересное, что через несколько дней может опять восстановиться запрос с UNION, а может и нет..
Ребят, посоветуйте что можно сделать?


 
Сергей М. ©   (2009-05-18 08:28) [1]

При таких "чудесах" первое что напрашивается - это "чудеса" со значениями передаваемых параметров dt1 и dt2


 
MonoLife ©   (2009-05-18 08:38) [2]

Работает вот таким образом:
1-й запрос: SELECT <fields> FROM <base1> WHERE date1 BETWEEN :dt1 and :dt2 ORDER BY <field>
результат Ок

2-й запрос: SELECT <fields> FROM <base2> WHERE date1 BETWEEN :dt1 and :dt2 ORDER BY <field>
результат Ок

Одним запросом вместе с UNION - беда:(. Грубо говоря, еще вчера всё "работало" с теми же самыми параметрами и их значениями.

меня эти "чудеса" в могилу сведут.:(


 
MonoLife ©   (2009-05-18 09:36) [3]

вот, млин! Запустил этот запрос с UNION опять - нормальная выборка!..
Не могу поймать ситуацию когда происходят глюки:(


 
Sergey13 ©   (2009-05-18 09:37) [4]

> [2] MonoLife ©   (18.05.09 08:38)

Попробуй сделать 4 параметра, а не 2. Т.е. все параметры со своим именем.


 
MonoLife ©   (2009-05-18 09:43) [5]


> Sergey13 ©   (18.05.09 09:37) [4]

пробовал.. та же байда.. была..
ща раз 5 запустил запрос с UNION всё нормально..
Такое ощущение, что что-то мешало выполнить запрос, а теперь это "что-то" исчезло и работает как часы...


 
Anatoly Podgoretsky ©   (2009-05-18 10:02) [6]

В любом случае у тебя четыре параметра, Params[0]..Params[3], а не два, которые имеют необязательные имена.


 
MonoLife ©   (2009-05-18 10:37) [7]


> Anatoly Podgoretsky ©   (18.05.09 10:02) [6]

Понятно.
Если б это еще решало проблему...


 
Sergey13 ©   (2009-05-18 11:16) [8]

> [2] MonoLife ©   (18.05.09 08:38)
> Грубо говоря, еще вчера всё "работало" с теми же самыми
> параметрами и их значениями.

А вчера

> базы dbf (не мои).

Были те же? Или они постоянно "свежие"?


 
Медвежонок Пятачок ©   (2009-05-18 11:18) [9]

Грубо говоря, еще вчера всё "работало" с теми же самыми
> параметрами и их значениями.


И сегодня "работает".
Но записи другие.


 
MonoLife ©   (2009-05-18 11:39) [10]


> Sergey13 ©   (18.05.09 11:16) [8]

>Были те же? Или они постоянно "свежие"?

та же база, накапливаются данные.
Я запрашиваю данные за текущий месяц.

> Медвежонок Пятачок ©   (18.05.09 11:18) [9]

> Но записи другие.

Записи те же, просто их может (или не может) стать больше чем вчера.
Так вот. Вчерашний запрос за текущий период выдал мне нужное, а сегодня - нет.. Точнее потом, вдруг выдал:)
Параметры к запросу всегда одни и те же, ну.. применимо к текущему периоду.. с 1-го по последний день месяца, к примеру..


 
Anatoly Podgoretsky ©   (2009-05-18 11:42) [11]

Ты игнорируешь знание, что у тебя четыре параметра.


 
Медвежонок Пятачок ©   (2009-05-18 11:46) [12]

Записи те же, просто их может (или не может) стать больше чем вчера.

Вот они и другие (тех кого стало больше чем вчера)


 
Sergey13 ©   (2009-05-18 11:55) [13]

> [10] MonoLife ©   (18.05.09 11:39)

А может в момент "неработоспособности" запроса идти какая нибудь переиндексация этих файлов с другой машины или что-то в этом роде? Совместная работа в общем не вмешивается временно в процесс?


 
MonoLife ©   (2009-05-18 12:01) [14]


> Anatoly Podgoretsky ©   (18.05.09 11:42) [11]

Нет, не игнорирую.. Первое, что я сделал, когда UNION перестал работать я указал 4 параметра, вместо 2-х.

ParamByName("dt1").DataType:=ftDate;
ParamByName("dt1").value:=StrToDate("01.05.2009")
ParamByName("dt2").DataType:=ftDate;
ParamByName("dt2").value:=StrToDate("31.05.2009")

ParamByName("dt3").DataType:=ftDate;
ParamByName("dt3").value:=StrToDate("01.05.2009")
ParamByName("dt4").DataType:=ftDate;
ParamByName("dt4").value:=StrToDate("31.05.2009")
Результата это не дало...

> Медвежонок Пятачок ©   (18.05.09 11:46) [12]

И что? Они тоже имеют значение TDATE - текущую дату.. Тем более, что утром не работало, а сейчас работает, причем база не менялась в течение дня.
Не ребят, без разницы, все телодвижения с программным кодом не дают никаких результатов.. UNION то работает, то нет по какой-то своей прихоти...
Я надеялся, что кто-то скажет, что да, такое может быть у BDE при работе с dbf по причине глюков в системе, может быть... я не знаю:(


 
Медвежонок Пятачок ©   (2009-05-18 12:02) [15]

И что? Они тоже имеют значение TDATE - текущую дату..

Ну имеют.
Причем такое значение, которое не попадает в твое условие выбора.


 
MonoLife ©   (2009-05-18 12:02) [16]


> Sergey13 ©   (18.05.09 11:55) [13]

все локально.

> Совместная работа в общем не вмешивается временно в процесс?

как бы не запускаю никаких других процессов, связанных с этой базой


 
MonoLife ©   (2009-05-18 12:03) [17]


> Медвежонок Пятачок ©   (18.05.09 12:02) [15]

>Причем такое значение, которое не попадает в твое условие выбора.

Если условие с 1 по 30 мая, то как могут не попасть в условие записи, которые еще вчера попадали?


 
MonoLife ©   (2009-05-18 12:04) [18]


> Медвежонок Пятачок ©   (18.05.09 12:02) [15]

Не забываем, что по отдельности (без UNION) все записи выбираются


 
Медвежонок Пятачок ©   (2009-05-18 12:05) [19]

Они тоже имеют значение TDATE - текущую дату..

А параметры тоже содержат значение TDateTime.
Причем скорее всего с элементом времени не равным 00:00:00


 
Медвежонок Пятачок ©   (2009-05-18 12:05) [20]

Не забываем, что по отдельности (без UNION) все записи выбираются

Union All


 
Anatoly Podgoretsky ©   (2009-05-18 12:41) [21]


> Не забываем, что по отдельности (без UNION) все записи выбираются

Это как бы два разных отчета, второй добавлен в конец первого и далее отсортирован. Не может не работать, у тебя проблема не с запросами, а возможно с порушеной системой, например сбитые индексы. С Union план разный.


 
Anatoly Podgoretsky ©   (2009-05-18 12:43) [22]


> Причем скорее всего с элементом времени не равным 00:00:
> 00

В данном случае без разницы, просто получит не все данные.


 
Anatoly Podgoretsky ©   (2009-05-18 12:45) [23]

Кстати ему особо верить нельзя, поскольку даже базы с таблицами путает.


 
Медвежонок Пятачок ©   (2009-05-18 12:46) [24]

By default, non-distinct rows are aggregated into single rows in a UNION join. Use ALL to retain non-distinct rows.


 
MonoLife ©   (2009-05-18 14:38) [25]


> Anatoly Podgoretsky ©   (18.05.09 12:45) [23]
>
> Кстати ему особо верить нельзя, поскольку даже базы с таблицами
> путает.

особо - да:)

> Anatoly Podgoretsky ©   (18.05.09 12:41) [21]
>...а возможно с порушеной системой, например сбитые индексы...

эм.. они что, то рушатся, то сами восстанавливаются?

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


 
MonoLife ©   (2009-05-18 14:44) [26]


> Медвежонок Пятачок ©   (18.05.09 12:46) [24]

сорри. упустил твой пост..
спасибо, посмотрим, как долго это продержится...


 
Anatoly Podgoretsky ©   (2009-05-18 14:53) [27]


> MonoLife ©   (18.05.09 14:38) [25]

У меня пока других предположений нет.


 
MonoLife ©   (2009-05-18 15:43) [28]


> Anatoly Podgoretsky ©   (18.05.09 14:53) [27]

ясно....Если есть вероятность проблемы с индексами, то тогда вполне может быть такая котовасия..
Я, всё же, грешу на какие-то, ранее запущенные и не выгруженные, процессы в системе.. Но кто их запустил и кто потом выгрузил?..

Кстати, Anatoly,  поясните, если не трудно, плз,

>С Union план разный


 
Anatoly Podgoretsky ©   (2009-05-18 16:07) [29]

> MonoLife  (18.05.2009 15:43:28)  [28]

Тут не пояснять нужно, а причину искать.
Для начала переиндексировать таблицы, не помню но возможно это можно сделать с помощью DBD


 
MonoLife ©   (2009-05-18 17:21) [30]


> Тут не пояснять нужно, а причину искать.

Рад бы в рай...
Есть штатное средство для проверки этих таблиц (шло с ними). Лечил, проверял на всякий случай, там всё было в порядке.. Да и спец. ПО, использующее эти файлы работает, не глючит...
Ладно, спасибо, что уделили мне время..
Теперь до следующего раза.. может отловлю момент когда это происходит..


 
AndreyV ©   (2009-05-19 05:21) [31]

> [30] MonoLife ©   (18.05.09 17:21)
> Теперь до следующего раза.. может отловлю момент когда это
> происходит..

И сохрани базу в этом состоянии куда-нибудь, там и копай.

> [25] MonoLife ©   (18.05.09 14:38)
> > Anatoly Podgoretsky ©   (18.05.09 12:41) [21]
> >...а возможно с порушеной системой, например сбитые индексы...
>
> эм.. они что, то рушатся, то сами восстанавливаются?
>
> Я понимаю, если бы всегда выполнялся запрос или никогда
> не выполнялся...

Если они порушены, может быть что угодно.
И ты не уточнил, для полноты картины, файлы FoxPro или чьи другие.


 
MonoLife ©   (2009-05-19 16:08) [32]


> AndreyV ©   (19.05.09 05:21) [31]
> Если они порушены, может быть что угодно

в таком случае, сторонняя программа, работающими с ними так же в ряд ли смогла работать, но этого не наблюдается.

Файлы не фоксовские. В bde - default driver=dbase, Langdriver = "ascii" ANSI

> И сохрани базу в этом состоянии куда-нибудь, там и копай.

Нет смысла...опишу чуть подробнее:
копирую базу к себе на комп. Локально с ней работаю (делаю те самые запросы). Так вот, без каких-либо махинаций с одними и теми же файлами dbf запрос с Union то работает, то не нет..
Второе, что я сделал после глюка с запросом, это средствами проги, идущей с этими файлами, провел переиндексацию, упаковку и т.п... полечил, короче...
Глюк с запросом не исчез.. Просто, в середине дня, вдруг снова заработал..
Сегодня, кстати, работает))


 
AndreyV ©   (2009-05-19 17:23) [33]

> [32] MonoLife ©   (19.05.09 16:08)
> > И сохрани базу в этом состоянии куда-нибудь, там и копай.
>
> Нет смысла...опишу чуть подробнее:
> копирую базу к себе на комп. Локально с ней работаю (делаю
> те самые запросы). Так вот, без каких-либо махинаций с одними
> и теми же файлами dbf запрос с Union то работает, то не
> нет..

Ты писал выше, что с разными, или тебе пофиг, что данные меняются? Или не так делаешь, как описываешь, или и впрямь барабашка.

> ParamByName("dt1").value:=StrToDate("01.05.2009")

Кстати, пользуйся лучше EncodeDate() - не зависит от текущей локали.


 
MonoLife ©   (2009-05-20 03:40) [34]


> AndreyV ©   (19.05.09 17:23) [33]


> или тебе пофиг, что данные меняются?

в каком смысле, пофиг?
Данные, конечно меняются, но в течение нескольких дней. А я делаю запрос к базе, на момент запроса, статичной. То есть, 2 таблицы утром - запрос не работает, те же самые таблицы без изменений вечером - работает.
Барабашка однако....

> Кстати, пользуйся лучше EncodeDate() - не зависит от текущей
> локали.

спасибо.


 
Нат   (2009-05-23 00:31) [35]

Странно, что не работает с четырьмя параметрами.
Очень странно, что запрос вообще работал с двумя параметрами... Поскольку Дельфи однозначно воспринимает все параметры в строке запроса как разные, вне заисимости от от совпадения имени.
Стоит исключить присваевание даты через текстовую переменную, параметры удобны тем, что можно делать через любой тип данных.
Присваивайте сразу тип TDate (TDateTime).
Заодно узнаете, все ли даты у Вас даты, и избежите проблем с "американским" форматом даты "mm/dd/yy"
Стоит проверить Parameters.Count, а также Parameters.Items [i]
Производится ли Parameters.ParseSQL?
Сделать вывод в лог состояния параметров и посмотреть.


 
KilkennyCat ©   (2009-05-23 00:43) [36]

Осталось спросить, не стоит ли Касперский. Эта зараза влияет даже если не стоит.


 
Нат   (2009-05-23 01:08) [37]

+
Достаточно, что он про нас думает
:-D


 
MonoLife ©   (2009-05-23 07:24) [38]


> Нат   (23.05.09 00:31) [35]

Советы исключительно полезные, спасибо.

> Очень странно, что запрос вообще работал с двумя параметрами.
> ..

Действительно странно.. Вот полгода с 2-мя параметрами работало..затем один, другой раз - сбой, затем опять все в порядке..
В любом случае, параметров теперь 4..

> Стоит исключить присваевание даты через текстовую переменную,
>  параметры удобны тем, что можно делать через любой тип
> данных.
> Присваивайте сразу тип TDate (TDateTime).

строковая переменная была лишь для примера, в программе, разумеется, используется ТDate...

> Производится ли Parameters.ParseSQL?

нет, а обязательно?

> Стоит проверить Parameters.Count, а также Parameters.Items
>

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


> KilkennyCat ©   (23.05.09 00:43) [36]
>
> Осталось спросить, не стоит ли Касперский. Эта зараза влияет
> даже если не стоит.

Не, заразы нема, NOD32, однако..))



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

Форум: "Начинающим";
Текущий архив: 2009.07.12;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.56 MB
Время: 0.005 c
2-1242731624
torcik
2009-05-19 15:13
2009.07.12
Рамер шрифта в width и height


2-1242886466
webpauk
2009-05-21 10:14
2009.07.12
Проверить строку


15-1241821510
Johnnnn
2009-05-09 02:25
2009.07.12
Тема по предыдущей теме таскбар в XP


9-1180737338
MERLIN:)
2007-06-02 02:35
2009.07.12
Как сделать спрайт


15-1242287623
Jolik
2009-05-14 11:53
2009.07.12
Работа: настроить сервер SourceSafe и интегрировать с Delphi





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский