Привет Всем!

Есть база больше, чем 4 ГБ. Необходимо сделать многотомную базу (по 2 ГБ файлик) для хранения на fat32.
Делаю через backup-restore. Но для 2-го, 3-го , n-го файлов в restore необходимо указать полный путь к файлу.
При подсоединении к БД (она может лежать в любой папке) ищутся 2-ой, 3-ий, n-ый файлы по точному пути, который был указан при restore.
Хотелось бы, чтобы 2-ой, 3-ий, n-ый файлы искались в папке рядом с 1-ым файлом.
Пробовал в restore не указывать полный путь к 2-ому, 3-ему, n-ому файлу - при подключении пытается найти их в windows/system32.
Использую firebird 2.1, может в новых версиях разрешили относительный путь для 2-ого, 3-его, n-ого файла?
Или только с помощью правки исходников firebird можно это победить?

МимопроходящийGreySerg> Необходимо сделать многотомную базу (по 2 ГБ файлик) для хранения на fat32.
не нужно этого делать.

Нужно, особенно для хранения БД на флешке, если на флешке будет NTFS, то вылетит вылетит намного быстрее, чем в FAT32, при постоянном вставке/удалении/обновлении данных в БД.
Мимопроходящийда, были когда-то давно утилиты позволяющие менять пути ко вторичным
файлам БД.
что-то типа "релинк", или наподобие.

Можно ссылку на такие утилиты?

Гаджимурадов РустамНу, многотомные базы-т о ещё ладно, но зачем сегодня fat32 да ещё на сервере?!

Сервером для программы может являться любая ОС, та же Windows XP, которая использует fat32 и еще очень популярна и распространена.

Dimitry SibiryakovGreySergесли на флешке будет NTFS, то вылетит вылетит намного быстрее, чем в FAT32

Из какого пальца ты высосал эту ерунду?

PS: Не надо БД хранить на флэшке.

NTFS - журналируемая файловая система, кроме записи данных на флешку пишется еще и журнал, что увеличивает износ флешки.
Не надо мне говорить, что не надо использовать fat32 и флеш, ПО успешно работает с 2007 года , сейчас возникла проблема с превышением БД 4 ГБ. Решение проблемы с помощью конвертации в NTFS - неудобно с точки зрения поддержки, т.к. многие клиенты имеют очень плохое компьютерное образование и еще существуют проблема замедления скорости и износа флешки на NTFS.
exFAT для флешек не подходит, т.к. надо с собой носить драйвера.

Дело в том что баз, превысивших 4 ГБ, - несколько тысяч, не одна.

Мимопроходящийхрани бекапы, они меньше.

Не понимаю, как бэкапы могут решить проблему превышения базы 4 ГБ у тысяч клиентов. Бэкап-рестор немного уменьшает БД (делает меньше 4 ГБ), но это не надолго.

hvladGreySergNTFS - журналируемая файловая система, кроме записи данных на флешку пишется еще и журнал, что увеличивает износ флешки.И что же, по твоему, пишется в этот журнал ?
Журнал USN

Мимопроходящийыщо раз.
ненужно хранить базу на флешке.
тем более на фат32.
ненужно заставлять сервер работать с базой,
которая лежит на флешке.

для упёртых: утилита называется ibrelink,
автор - Danny Mavromatis.

C флешкой работает Embedded firebird.
Спасибо за утилиту.

AriochGreySergNTFS - журналируемая файловая система, кроме записи данных на флешку пишется еще и журнал

Ну отключи его. Как и дату "последнего обращения к файлу"

Кстати, по-моему как раз данные в жyрнал не пишутся, по-моему ты путаешь NTFS и ext4
Как отключить журнал в NTFS, даже если это возможно, это внедрение в систему безопасности клиента, что не очень хорошо.
Я дал ссылку с википедии.

AriochGreySergКак отключить журнал в NTFS

Google + 2 seconds

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fsutil_usn.mspx?mfr=true


GreySergэто внедрение в систему безопасности клиента

Да-да-да, настройка - даже не форматирование - моей флэшки относится к СБ клиента.
Флешка не ваша, а клиента, и объяснить клиентам, как это сделать по этой статье - сложная задача.
А вот сравнение работы флешек на разных файловых сиcтемах.
И тут написано, что: С другой стороны NTFS крайне надежная файловая система, выдерживающая не один внезапный ресет. Такая надежность обеспечивается журналированием. Это приведет к тому, что система будет чаще обращаться к определенным областям накопителя. Для флешек и карт памяти такой подход критичен. Они будут изнашиваться быстрее.

Мимопроходящийутилита называется ibrelink,
автор - Danny Mavromatis.

может кто-нибудь дать ссылку на эту утилиту, что-то не могу найти

kdvGreySerg,

что-то я ibrelink не упомню, а вот glink - да.
http://www.ibase.ru/download/glink.zip
Спасибо.
Но судя по описанию здесь этой утилиты, это не совсем то, что мне нужно. Эта утилита меняет известный путь на такой же известный, а мне надо чтобы 1-ый *.fdb файл видел остальные n файлов, лежащие в этой же папке, где 1-ый, и папка была любая, т.е. пример:
БД из 3-х файлов: D:\Test\db.fdb, D:\Test\db.fd2, D:\Test\db.fd3
Соединяемся с D:\Test\db.fdb, соответственно коннектятся и остальные части fd2 и fd3 (Все хорошо, т.к. я делал restore всех частей в папку D:\Test).
Переносим 3 файла db.fdb, db.fd2, db.fd3 в новую папку F:\Test2. При коннекте с F:\Test2\db.fdb у меня будет ошибка, т.к. не найдет 2 файла D:\Test\db.fd2, D:\Test\db.fd3, которых естественно там нет (мы их перенесли в папку F:\Test2).
Есть 2 варианта решения:
1) Изменить исходники firebird, чтобы он видел вторичные файлы рядом в этой же папке
2) Перед коннектом к F:\Test2\db.fdb необходимо запускать утилиту glink и менять путь к вторичным файлам.
Если я неправ, поправьте пожалуйста.

Или все же не заморачиваться с многотомами на флешке, а конвертировать флешку в NTFS и не парится по скорости работы флешки и вопросу быстрого вылета флешек на NTFS.
Вы же утверждаете, что всего вышеописанного на флешках NTFS - нет, все быстро работает на NTFS и срок службы флешки такой же как и на Fat32.
Мои приведенные ссылки утверждают обратное.
Есть ли у вас аргументированное обоснование "моих заблуждений"?
Пока кроме высказываний
Dimitry SibiryakovТо, что там написано относится к обычной работе с файлами - создание, копирование,
удаление. БД работает совсем иначе. Именно поэтому износ за счёт журнала - ерунда. и
zirraНа второй бы мессаге начал грубить и пальцем в ТТХ флешек тыкать...?

я ничего не увидел.

kdvGreySerg мне надо чтобы 1-ый *.fdb файл видел остальные n файлов, лежащие в этой же папке, где 1-ый
то, чего тебе надо, никогда не будет, потому что пути вторичных файлов жестко зашиты в БД. Увы, так это сделано, и вряд ли кто будет это менять сейчас, потому что вторичные файлы уже давно никому не нужны.
То что мне надо , может быть, если я изменю исходники firebird (1 вариант)
AriochGreySerg,

есть ещё полтора варианта

15530593 15530631
И чем же мне поможет subst и symlink?

AriochGreySerg,

установкой одного пути типа s:\111fdb s:\222.fdb s:\333.fdb для всех файлов на любой машине
Согласен , subst и symlink хороши.
Надо попробовать.
Ariochони описывают совсем другие сценарии работы. в вашем же случае - как вы его описали - журнал может быть (за исключением увеличчения файла FDB) можно вообще не обновлять
На флешке пользователь может хранить не только базу firebird, но и свои данные и мы ухудшаем работу с флешкой, заставляя пользователя конвертировать в ntfs для работы с базой.

МимопроходящийHello, GreySerg!
You wrote on 7 февраля 2014 г. 15:03:10:

GreySerg> На флешке пользователь может хранить не только базу firebird, но и свои
> данные и мы ухудшаем работу с флешкой, заставляя пользователя
> конвертировать в ntfs для работы с базой.
ыщо раз.
ничего ХРАНИТЬ на флешке не нужно.
флешка для этого не предназначена.
никаких жизненно важных данных.

В моем случае, база firebird - НЕ жизненно важные данные, если что-то повредится , мы перепишем клиенту новую БД.

МимопроходящийHello, GreySerg!
You wrote on 7 февраля 2014 г. 15:19:04:

GreySerg> В моем случае, база firebird - НЕ жизненно важные данные, если что-то
> повредится , мы перепишем клиенту новую БД. пишите на DVD.



На DVD нельзя обновлять базу firebird.

МимопроходящийHello, GreySerg!
You wrote on 7 февраля 2014 г. 16:00:48:

GreySerg> На DVD нельзя обновлять базу firebird.
запишете новый DVD.

Клиент обновляет базу firebird нашими файлами мелкими (ежедневно через интернет), если только БД у него повредится (крайний случай), только тогда мы ему пишем новую базу, так что DVD ну никак не подходит.

AriochGreySergНа флешке пользователь может хранить не только базу firebird, но и свои данные и мы ухудшаем работу с флешкой, заставляя пользователя конвертировать в ntfs для работы с базой.

ДАйте ему программУ, которая флэшку разобьёт пополам, на диск с фаербердом и диск с данными.

Тем более, что флэшку вообще не стоит забивтаь данными "под завязку". Уж лучше иногда всё скопировать на диск а потом на чистую флэшку обратно
Флешка не одна, их много у разных клиентов, и каждый клиент сам решает, что с ней делать, хочет использовать нашу программу с firebird, хочет нет, и мы вправе ему только рекомендовать. Сейчас рекомендуем конвертировать в ntfs, чтобы программа работала, но хотелось бы этого не делать, поэтому и ищу решение с многофайловой БД.