Конференция "Базы" » Грамотное освобождение SQL-запроса в DLL [dBase, FoxPro]
 
  • Oleg__L (07.11.09 08:53) [0]
    Win XP, Delphi 2006, Word 2003
    Нужно из word-a обратиться к .DBF. Бэйсик я знаю плохо, поэтому решил написать процедуры SQL запроса в Delphi и скомпилировать dll

    procedure CreateQuery(DBPath: PChar); export; stdcall;
    begin
    Query:= TQuery.Create(nil);
    Query.DatabaseName:= DBPath;
    end;

    procedure FreeQuery; export; stdcall;
    begin
    Query.Active:= False;
    Query.Free;
    end;


    В басике специфические строки поэтому импорт/экспорт строк в делфовскую dll идет через PChar. Со строками проблем не возникало.
    Запускаю макрос в Ворде. Все проходит успешно. Сначала
    CreateQuery "мойпуть"
    затем остальные функции из dll по выборке из dbf. Все работает отлично. Затем
    FreeQuery
    Макрос завершен успешно. База выведена и отсортирована.
    Вот только если я второй раз макрос запущу басик кричит "Недостаточно памяти". И папка Temp в профиле быстро заполняется. Как будто FreeQuery не освободил память.
    В чем дело? Кого винить? Басик, Делфи или себя?
  • Loginov Dmitry © (07.11.09 14:09) [1]
    > Как будто FreeQuery не освободил память.


    Какая связь между FreeQuery и папкой Temp?


    > Кого винить? Басик, Делфи или себя?

    Обычно - последнее.
  • Oleg__L (07.11.09 14:52) [2]
    >Обычно - последнее.
    Не надо меня в орешник :D
    >Какая связь между FreeQuery и папкой Temp?

    обьект типа TQuery когда делает выборку создает временные .dbf файлы в текущем каталоге. Если прога завершилась успешно то они удаляются. А папку Temp скорее всего Word засоряет.
    Раз не хватает памяти значит таблица не выгружается.

    Я так понимаю

    Query.Active:= False;
    Query.Free;



    выгрузит таблицу и сам объект Query
  • sniknik © (07.11.09 15:25) [3]
    у BDE бывает "Недостаточно памяти", но часто это вовсе не значит что ее недостаточно, а скорее то что с ним неправильно работают.
    не скажу точно, не помню,да и не занимался  никогда BDE "вплотную" (тесты и вопросы с форума не в счет), но там вроде ограничение на количество открытых "инстансов" по умолчанию. (проверить, бросить на форму TTable, открыть в нем простую таблицу при старте, скомпилить. а после запустить полученную прогу например 15 раз (чтоб 15 копий работающих с открытой таблицей висело)... думаю не удастся)
    исправляется это не простым закрытием таблицы, а закрытием базы/"инстанса" т.е. в нем работы создается какое то "ядро", и вот его нужно закрывать.

    заниматься, так сказать, некромантией. т.е. восстанавливать утерянные (да и не нужные особо никогда) навыки само собой неохота, т.что давай сам. а лучше все таки сделай в бейсике. с использованием ADO/Jet (блин, да все примеры в справке на бейсике... там, имхо, можно прямо готовое решение найти...)
  • Loginov Dmitry © (07.11.09 23:18) [4]
    > Не надо меня в орешник :D


    Боже упаси! Причем здесь орешник?


    > обьект типа TQuery когда делает выборку создает временные
    > .dbf файлы в текущем каталоге. Если прога завершилась успешно
    > то они удаляются. А папку Temp скорее всего Word засоряет.
    > Раз не хватает памяти значит таблица не выгружается.


    Насчет временных файлов .dbf опровергнуть не могу. Обычно в процессе
    сортировки больших объемов данных DBE создает временные файлы .db, которые
    в идеале должны автоматически удаляться, а на деле - как звезды лягут.

    Но причем тут временные .dbf файлы в текущем каталоге и папка Temp, которую
    засоряет Word? Чем он ее засоряет, при каких обстоятельствах и для каких целей?
  • Loginov Dmitry © (07.11.09 23:22) [5]
    > чтоб 15 копий работающих с открытой таблицей висело)...
    > думаю не удастся


    По умолчанию облом будет уже при 11 подключениях.

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


    Зачастую исправляется только полным перезапуском всех приложений,
    работающих с Paradox.
  • Германн © (08.11.09 03:30) [6]

    > Зачастую исправляется только полным перезапуском всех приложений,
    >
    > работающих с Paradox.

    Да ещё порой и с ручным поиском специфических файлов, для ручного убиения. А на закуску ещё и с перезапуском ОС.
  • sniknik © (08.11.09 12:11) [7]
    странные у вас были программы... у нас одна была с использованием BDE/Paradox (не я писал), на редкость стабильно работала... ни чем вами вменяемым не страдала...

    вообще я там только раз один странный глюк встречал (писал про это может кто помнит), в одну таблицу перестали добавляться записи как будто превысился размер (ну там у них есть 64/128/256/.../2048 мег. в зависимости от минимального размера страницы), хотя размер у нее после паковки стал 4 мега (примерно, но точно до 10, а до, она да, при глюке была под 128, установленный максимум), т.е. там почему-то перестало место повторно использоваться, почему я тогда не понял, исходный файл не сохранил, просто исправил упаковкой, второй раз такого не наблюдалось, в общем это осталось тайной покрытой мраком...
    а и да, было это естественно у клиентов, у них вообще много глюков было, которые в итоге объяснялись тем что они сами что-то не так скопировали, или не то удалили и т.д., а на стенде с прогой чего только не делали... (ну кроме явных глупостей как клиенты) - работала. без "мусора", без перезапусков, без нехваток памяти (сабж), индексы сама восстанавливала (штатная установка была простым копированием, а т.к. это еще во времена дискеток начиналось... место было довольно важным, поэтому индексы просто удаляли и копировали только прогу с данными, т.е. восстановление это было побочным эффектом этого)
  • Loginov Dmitry © (08.11.09 12:49) [8]
    > странные у вас были программы... у нас одна была с использованием
    > BDE/Paradox (не я писал), на редкость стабильно работала...
    > ни чем вами вменяемым не страдала...


    Повезло значит. Возможно, что ваши программисты не допускали никаких
    ошибок в своем ПО. Это очень важно, т.к. с Парадоксом нужно работать
    очень и очень аккуратно. Но эта аккуратность все равно не может избавить от
    многочисленных внутренных ошибок в Парадоксе. Поэтому повезло значит :)
  • Mike Kouzmine (09.11.09 10:15) [9]
    Если бде, то может из-за переполнения файла блокировок. Посмотри в каталоге с таблицами парадокс.лск. Уже не помню расширение. Но что-то вроде
  • Oleg__L (09.11.09 10:56) [10]
    >Но причем тут временные .dbf файлы в текущем каталоге
    например такой:_QSQL000.DBF
    А временные .db вообще не создаются
    >Чем он ее засоряет, при каких обстоятельствах и для каких целей?
    \local settings\Temporary Internet Files\Content.Word
    ~wrs0000.tmp, ~wrs0001.tmp, ...

    заменил TQuery на TADOQuery
    Та же ошибка. Вывод: все таки
    Query.Active:= False;
    Query.Free;


    недостаточно, чтобы выгрузить таблицу
  • sniknik © (09.11.09 11:07) [11]
    > заменил TQuery на TADOQuery
    > Та же ошибка.
    при работе с dbf jet сам в свою очередь использует BDE, если установлено. делайте выводы господа. т.е. заменив, ты ничего не поменял... кроме пути к нему, он стал длиннее.

    чтобы переключить на безусловное использование "встроенного в jet BDE" нужно в реестре ключ BDE добавить и что то там (не помню, посмотри в msde) прописать.
  • Oleg__L (10.11.09 14:51) [12]

    > а лучше все таки сделай в бейсике. с использованием ADO

    Я так и сделал. Гы.. та же ошибка... Алгоритм выгрузки таблицы использую тот же.
    Ну это уже не в этот форум. Всем спасибо!
  • sniknik © (10.11.09 15:49) [13]
    > Гы.. та же ошибка...
    ответ прямо над твоим постом.
 
Конференция "Базы" » Грамотное освобождение SQL-запроса в DLL [dBase, FoxPro]
Есть новые Нет новых   [134435   +33][b:0][p:0.001]