freepascal.ru

Привет all!

На форуме недавно, не знал куда написать, написал сюда.
В TSQLite3Dataset наблюдаю следующую вещь: при изменении значения FileName в "инспекторе объектов" путём выбора файла в дальнейшем невозможно работать с БД, которая находится по-умолчанию в каталоге с программой. При изменении этого свойства на (существующую) "database.db" создаётся таблица с таким именем в домашнем каталоге.
Возможно, кто-нибудь проверит и запостит ошибку на багтрекере..

Ubuntu 9.10
Lazarus 0.9.28.2-0

TSQLite3Dataset позволяет работать только с одной базой данных, путь к которой прописывается в FileName. если вам необходимо данный компонент использовать с несколькими БД, то необходимо либо перепрописывать FileName, либо использовать второй компонент TSqliteDataset

Padre_Mortius писал(а):TSQLite3Dataset позволяет работать только с одной базой данных, путь к которой прописывается в FileName. если вам необходимо данный компонент использовать с несколькими БД, то необходимо либо перепрописывать FileName, либо использовать второй компонент TSqliteDataset

Вы меня неправильно поняли. Попробую объяснить ещё раз. Раньше я мог указать "database.db" для имени файла и компонент работал с БД, находящейся в в каталоге с программой. Теперь компонент ищет БД не в каталоге с программой, а в домашнем (/home/username) каталоге, а не находя, создаёт.

Сории. неправильно понял. В общем это все-таки наверное не баг, а фича. Если не указываем полный путь, а только относительный, то при нормальном подходе к безопасности и разграничению прав, единственной доступной папкой на запись является папка профиля

Добавлено спустя 2 минуты 59 секунд:
Да и жесткая привязка базы к определенной папке, по моему мнению, не есть хорошо. Случаи всякие бывают. поэтому всегда делаю данный параметр настраиваемым

Хм, об этом конечно не подумал... Но странно, согласись: сначала я указывал просто имя файла и было всё нормально, БД лежал там, где должен по-умолчанию. Но стоило мне только 1 раз нажать на изменение этого параметра и, даже не указывая, просто отменить - ничего не работает как раньше...
Если это на самом деле фича, то она с багом

А путь нигде не меняется в проекте? Посмотрел внимательнее и не получил такой баг. Правда проверял по Win32. Как только Буду дома, то проверю под CentOS. Но вроде там тоже ругался если не вводить полный путь. В исходниках ничего похожего на папку профиля нет.

Путь меняется при нажатии баттона, но это не имеет значения. Банально невозможно переключить свойство TSQLite3Dataset Active в True, ругается на отсутствие таблиц в БД, которую только что создал
Если вписать вместо "database.db" "./database.db" то проблема решается. Но ведь раньше так не нужно было делать, ога...

свежая svn ревизия от 25-12-2009 lazarus.

Если вписать вместо "database.db" "./database.db" то проблема решается

Получаю сообщение "SQLITE_ERROR - no such table"

И все таки более грамотно будет писать полный путь к базе данных в поле FileName

prom-net-pixel писал(а): ругается на отсутствие таблиц в БД, которую только что создал

Padre_Mortius писал(а):Получаю сообщение "SQLITE_ERROR - no such table"

Это, вобщем, одно и то же.

prom-net-pixel писал(а):Если вписать вместо "database.db" "./database.db" то проблема решается. Но ведь раньше так не нужно было делать, ога...

-это для линуха.
Дак как ? Это ошибка или нет? Так, сами разберутся

Добавлено спустя 8 минут 42 секунды:

Padre_Mortius писал(а):И все таки более грамотно будет писать полный путь к базе данных в поле FileName

Всё-таки вопрос не в том, что более грамотно, а в том, как это должно работать.

Судя по коду компонента в поле FileName должен заносится полный путь к базе данных, т.к. никаких подстановок в коде нет

prom-net-pixel
А Вы, когда программа работает правильно и когда неправильно, проверьте, в каком каталоге находитесь с помощью функции GetCurrentDir и тогда сразу всё станет ясно.

Сдается мне что даже если и есть возможность правильного указания имени к базе, всеравно ето больше баг а не фича. ибо по моему опыту естественно начинать поиск файлов в каталоге с программой а не в гдето еще.
для линуха может быть ето и нетак но насколько я понял на виндовс вообще забили. ето раз.
имхо, любые изменения\фиксы\нововведения должны по максимуму обеспечивать обратную совместимость кода\преемственность. а тут она нарушена 100%. ето два.
имхо надо постить рапорт о баге.

alexrayne писал(а):... ибо по моему опыту естественно начинать поиск файлов в каталоге с программой а не в гдето еще....

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

Начинать поиск с папки рядом с программой неправильно в любом случае вне зависимости от операционки. Windows позволяет это делать для совместимости с досом, но категорически не рекомендует так делать!
Для хранения данных программы в windows есть реестр и несколько специально отведенных папок, например ApplicationData, ProgrammData и т.д.

Начинать поиск с папки рядом с программой неправильно в любом случае вне зависимости от операционки. Windows позволяет это делать для совместимости с досом, но категорически не рекомендует так делать!
Для хранения данных программы в windows есть реестр и несколько специально отведенных папок, например ApplicationData, ProgrammData и т.д.

а в чем проблемато? насколько я понимаю поиск в каталогах пользователя типа home требуется для поддержки многопользовательскости, если етого ненужно то невижу никакой беды в этом.
я пишу проги на винду тоже, и мне для простоты использования неохота заниматься связями с реестром и пользовательскими настройками если я могу прекрасно обойтись без этого. а возможность обойтись без установки программы и обойтись простым ее копированием я весьма ценю. так что претензии против примитивизма DOSа мне както неукладываются. если его хватает для повседневного пользования то зачем отбрасывать? а если вы уж затачиваетесь под многопользовательскость, то какие проблемы явно запользовать пользовательские папки.

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