Re: Linux-клиент к Windows-серверу FB2.1
1) не смогли найти диск с инсталляшкой linux 2) не смогли найти диск с инсталляшкой винды. 3) нашли диски но не смогли установить. 4) установили ОС, но не смогли настроить. 5) настроили ОС, но не смогли установить клиента firebird 6) установили клиента firebird, но оказалось что длины кабеля не хватает для объединения двух компьютеров в сеть. и т.д. Как видишь, очень много камней. Но если все это решить, то работать будет. Гоголь Дмитрий wrote: Здравствуйте, уважаемые. Подскажите, пожалуйста, какие могут быть подводные камни у связки Linux-клиент к Windows-серверу (FireBird 2.1).
Re: Как правильно организовать работу.
Устранить проблему удалось только путем добавления Sleep(5000) после ShutDown-а и перехода к DML. Но как решение задачи это не подойдет - не надежно. В общем, IMHO, какая-то рассинхронизация процессов происходит в Classic-е при работе по подобному сценарию. С уважением, Самохвалов Григорий Если клиентское приложение одно, или имеется контроль над сырцами всех клиентских приложений, работающих с базой, то можно пойти по пути EVENTов. Типа есть процедура: CREATE OR ALTER PROCEDURE POSHLI_VSE_NA AS BEGIN POST_EVENT 'VON_IZ_BAZI'; END Ну, а когда клиентские приложения получают такое сообщение, то дружно все отваливаются. Изврат конечно, но пользовал его давно, еще с эпохи InterBase 6 до того момента, когда появился Firebird двойка. Сбоев ни разу не было, хотя теоретически способ вроде бы не надежный.
Re: Linux-клиент к Windows-серверу FB2.1
On Thu, 10 Sep 2009 11:15:47 +0500, Kochmin Alexandr alexa...@intakom.ru wrote: Как видишь, очень много камней. Но если все это решить, то работать будет. Улыбнуло. :-) Т.е. каких-то специфических особенностей, кроме обязательного корректного указания кодовой страницы, не выявлено. Это радует. -- Гоголь Дмитрий
Re[2]: Linux-клиент к Windows-серверу FB2.1
Привет! Т.е. каких-то специфических особенностей, кроме обязательного корректного указания кодовой страницы, не выявлено. Это радует. Именно в такой связке - нет. Проблемы (единственные, как я помню) могут быть только при переносе базы, у которой есть _внешние_ таблицы, у которых прописан полный путь (при соответствующих настройках сервера). Тогда нужно их или дропнуть или не использовать абсолютные пути. А то винда устанет искать /var/db/external/table1.dat :) -- Best regards, Sergeymailto:gebele...@gmail.com
Re: Linux-клиент к Windows-серверу FB2.1
Sergey Mereutsa wrote: Привет! Т.е. каких-то специфических особенностей, кроме обязательного корректного указания кодовой страницы, не выявлено. Это радует. Именно в такой связке - нет. Проблемы (единственные, как я помню) могут быть только при переносе базы, у которой есть _внешние_ таблицы, у которых прописан полный путь (при соответствующих настройках сервера). Тогда нужно их или дропнуть или не использовать абсолютные пути. А то винда устанет искать /var/db/external/table1.dat :) откуда вообще пошел разговор про кодовую страницу или абсолютные пути, если вопрос стоял просто в подключении с линукса на винду?
Re[2]: Linux-клиент к Windows-серверу FB2.1
Привет! откуда вообще пошел разговор про кодовую страницу или абсолютные пути, если вопрос стоял просто в подключении с линукса на винду? Ну как откуда? Если проблем нет, то их следует придумать! Просто при подключении можно смешивать операционки (и даже разрядности) в любых пропорциях. Я точно проверял (тока на 2+) связки (W - win, C - client, L - Lin, S - server, дальше разрядность): WC32+LS32 LC32+WS32 WC32+LS64 LC32+LS64 LC64+LS64 Винды 64-битной у меня нет, но не думаю, что там должны быть какие-то проблемы (окромя известных багов в _отображении_ статистики из-за разрядности). -- Best regards, Sergeymailto:gebele...@gmail.com
Re: Вопрос про [FB] data_page_manager
Я правильно понял, что есть две стратегии выделения места (под данные одной записи?) на data-страницах 2. если данные не могут поместиться, то выделяются orphan data-страницы + 1 блок, который размещается по правилу #1. Еще вопрос. Вторая стратегия отчасти обусловлена тем, чтобы на зарегистрированных data-страницах (на PP) не появлялись недоделанные блоки данных, которые могут начать парить моск при сканировании записей? под сканированием, я понимаю какой нибуть последовательный обход записей таблицы. --- И еще, я правильно понял, что на DP регистрируется последовательный номер родительской PP? Это дает какой то бонус по сравнению с регистрацией прямого индекса PP-страницы? Коваленко Дмитрий.
Re: Вопрос про [FB] data_page_manager
И еще, я правильно понял, что на DP регистрируется последовательный номер родительской PP? А, ну да. На DP регистрируется её последовательный номер, через который потом вычисляется PP Типа, если мы будем хранить прямой номер PP, то прийдется еще хранить и индекс слота на PP. Два байта экономится... Хотя можно и не хранить :) Коваленко Дмитрий.
Re: Вопрос про [FB] data_page_manager
Kovalenko Dmitry ... Я правильно понял, что есть две стратегии выделения места (под данные одной записи?) на data-страницах 2. если данные не могут поместиться, то выделяются orphan data-страницы + 1 блок, который размещается по правилу #1. Еще вопрос. Вторая стратегия отчасти обусловлена тем, чтобы на зарегистрированных data-страницах (на PP) не появлялись недоделанные блоки данных, которые могут начать парить моск при сканировании записей? Я эту терминологию не понимаю. Большие записи (р-р которых больше р-ра страницы) размещают свой хвост на отдельных выделенных страницах данных (DP), а начало записи помещается как обычная запись на нормальную DP. Выделенные под хвост DP не учитываются на PP т.к. их всё равно не возможно адресовать, не трогая начало записи. Т.е. если запись имеет размер N*P + M, где P - page size, то её хвост будет размещён на N выделенных страницах и начало, размером M, будет помещено на общую DP. под сканированием, я понимаю какой нибуть последовательный обход записей таблицы. --- И еще, я правильно понял, что на DP регистрируется последовательный номер родительской PP? Нет. На DP записывается её собственный логический (последовательный) номер (см. Ods::data_page::dpg_sequence). Он используется, например, для валидации. Ну и для разборов полётов тоже, есс-но. -- Хосун Влад
Re: Вопрос про [FB] data_page_manager
Kovalenko Dmitry ... Большие записи (р-р которых больше р-ра страницы) размещают свой хвост на отдельных выделенных страницах данных (DP), а начало записи помещается как обычная запись на нормальную DP. Выделенные под хвост DP не учитываются на PP т.к. их всё равно не возможно адресовать, не трогая начало записи. Т.е. если запись имеет размер N*P + M, где P - page size, то её хвост будет размещён на N выделенных страницах и начало, размером M, будет помещено на общую DP. Ну да. Я к тому что если начать размазывать запись на фрагменты по существующим (нормальным/зарегистрированным на PP) DP, Зачем ? Чтобы сделать как можно меньше нормальных записей на странице ? :) то будет период существования недоделанных записей. То есть 1. Блокируем DP_1. пишем кусок на DP_1. Разблокируем DP_1 2. Блокируем DP_2.пишем кусок на DP_2. Разблокируем DP_2 ... N. Блокируем DP_N.пишем кусок на DP_N. Разблокируем DP_N Если в процессе кто-то начнет читать/анализировать эти DP_x страницы, то он обнаружит недоделаную запись. Кто именно - я ахез. А то мы не умеем отличать нормальную версию записи от фрагмента :) А текущая стратегия номер #2 гарантирует что недоделанные (хвостовые) куски появлятся не будут. И параллельно работающие алгоритмы не будут впадать в ступор, если вдруг начнут лезть к этим недоделанным кускам. Они и так не будут впадать в никуда. Нет. На DP записывается её собственный логический (последовательный) номер (см. Ods::data_page::dpg_sequence). Он используется, например, для валидации. Ну и для разборов полётов тоже, есс-но. Ну да... Но что бы потом перейти к родительской PP, надо - либо перебирать список PP - либо юзать и поддерживать в актуальном состоянии in-memory копию этого списка (оформленную в виде массива). Это у вас так сделано. Список PP живёт в RDB$PAGES и дополнительно кеширован в памяти А так - прочитали на DP номер родительской PP и все прыгаем на неё без всяких заморочек. А в чём заморочка ? Или всё, что тебе не понятно - уничтожить ? :-D -- Хорсун Влад
Re: Вопрос про [FB] data_page_manager
Большие записи (р-р которых больше р-ра страницы) размещают свой хвост на отдельных выделенных страницах данных (DP), а начало записи помещается как обычная запись на нормальную DP. Выделенные под хвост DP не учитываются на PP т.к. их всё равно не возможно адресовать, не трогая начало записи. Т.е. если запись имеет размер N*P + M, где P - page size, то её хвост будет размещён на N выделенных страницах и начало, размером M, будет помещено на общую DP. Ну да. Я к тому что если начать размазывать запись на фрагменты по существующим (нормальным/зарегистрированным на PP) DP, то будет период существования недоделанных записей. То есть 1. Блокируем DP_1. пишем кусок на DP_1. Разблокируем DP_1 2. Блокируем DP_2.пишем кусок на DP_2. Разблокируем DP_2 ... N. Блокируем DP_N.пишем кусок на DP_N. Разблокируем DP_N Если в процессе кто-то начнет читать/анализировать эти DP_x страницы, то он обнаружит недоделаную запись. Кто именно - я ахез. А текущая стратегия номер #2 гарантирует что недоделанные (хвостовые) куски появлятся не будут. И параллельно работающие алгоритмы не будут впадать в ступор, если вдруг начнут лезть к этим недоделанным кускам. Нет. На DP записывается её собственный логический (последовательный) номер (см. Ods::data_page::dpg_sequence). Он используется, например, для валидации. Ну и для разборов полётов тоже, есс-но. Ну да... Но что бы потом перейти к родительской PP, надо - либо перебирать список PP - либо юзать и поддерживать в актуальном состоянии in-memory копию этого списка (оформленную в виде массива). Это у вас так сделано. А так - прочитали на DP номер родительской PP и все прыгаем на неё без всяких заморочек. Коваленко Дмитрий.
Re: Вопрос про [FB] data_page_manager
А так - прочитали на DP номер родительской PP и все прыгаем на неё без всяких заморочек. А в чём заморочка? Да нету её. Я просто пытаюсь понять тайный смысл хранения последовательного номера data-страницы. Отбрасывая в сторону разборы полётов и валидацию. Что-то мне подсказывает, что его ценность равна ломанному яйцу :) Коваленко Дмитрий.
Re: Вопрос про [FB] data_page_manager
Kovalenko Dmitry ... А так - прочитали на DP номер родительской PP и все прыгаем на неё без всяких заморочек. А в чём заморочка? Да нету её. Я просто пытаюсь понять тайный смысл хранения последовательного номера data-страницы. Отбрасывая в сторону разборы полётов и валидацию. Ты недооцениваешь важность возможности разбора полётов и валидации Что-то мне подсказывает, что его ценность равна ломанному яйцу :) И вообще не серьёзно относишься к коду. Можешь мне не верить, но всё имеет свою причину. Гораздо чаще - правильную, чем наоборот. -- Хорсун Влад PS Ты бы хоть использование в коде dpg_sequence посмотрел...
А ты считаешь себя программистом?
Давайте узнаем сколько нас. Для этого голосуем здесь: http://www.visual2000.ru/other/survey/09_09_09_progday/index.htm -- Александр Замараев
