Ru-Board.club
← Вернуться в раздел «Прикладное программирование»

» InterBase и FireBird: вопросы по работе и их решение

Автор: exteris
Дата сообщения: 19.03.2013 07:52
ZIPKs

Цитата:
библиотеки использую от 32битного и поэтому не понимаю чего еще он хочет

Посмотрите в регистрационной информации базы в IBExpert-е, какой указан файл клиентской библиотеки и попробуйте указать путь к 32-битной.
Автор: delover
Дата сообщения: 19.03.2013 17:07
miwa
Между клиентом и сервером один и тот же протокол. Значит не влияет.
Сори. Кстати как сторонник скайпа и онлайн игр скажу что влияет.
Автор: miwa
Дата сообщения: 20.03.2013 11:14
Дабы убрать недоразумение.
Разрядность клиента и сервера, само собой, значения НЕ ИМЕЕТ. Точно так же не имеет значения ОС и архитектура процессора. До тех пор, пока пользователь не начинает пробовать запустить клиента и сервера на одном компьютере. И тогда - во избежание - лучше всего, если и клиент и сервер и соответствующее приложение будут компилированы под одну ОС и одну архитектуру.

Да, я тоже не дурак, и тоже запущу на одном компьютере сервер на линуксе под ARM, например, и виндовый клиент любой разрядности (ну или любую другую поддерживаемую firebird комбинацию). Но без понимания того, «кто кому рабинович» так лучше не делать, ибо скорее всего не получится.

Так понятнее?

P.S. Ответы extersis-а ближе всего к тому, что нужноZIPKs-у если он не хочет/не может следовать моим ответам. В связи с чем уточняющий вопрос ZIPKs-у: на основании чего утверждается, что
Цитата:
библиотеки использую от 32битного
? Только потому, что «мне так кажется» или есть более объективные данные?
Автор: delover
Дата сообщения: 21.03.2013 13:27

Цитата:
До тех пор, пока пользователь не начинает пробовать запустить клиента и сервера на одном компьютере.

FBServer - 64 FBClient - 32? Научите, я не умею ещё так. )

На счёт Linux согласен. Один клиент, на свой страх и риск, поставил сервер на Линух. В результате рухнувшая база не подлежит востановлению никакими тулзами.

На счёт 64 x 32. Многие сейчас ставят сервак 64. А клиенты на древних компиках с XP. Никто не жалуется, всё прекрасно, да и для этого и задумывалось.
Автор: miwa
Дата сообщения: 22.03.2013 00:45
delover


Цитата:
FBServer - 64 FBClient - 32? Научите, я не умею ещё так. )

Да вот человек как раз пытался. Если "дешево и сердито", то достаточно соответствующей 32-разрядной библиотеки рядом с 32-разрядным бинарником в 64-разрядной винде. Если немного правильнее, то нужен еще firebird.msg уровнем выше по файловой системе, или же нужны правильно установленные переменные окружения FIREBIRD и FIREBIRD_MSG.


Цитата:
На счёт Linux согласен. Один клиент, на свой страх и риск, поставил сервер на Линух. В результате рухнувшая база не подлежит востановлению никакими тулзами.

ОС здесь совершенно ни при чем. В IBSurgeon обращались?
Автор: delover
Дата сообщения: 22.03.2013 07:36
miwa

Цитата:
Если немного правильнее, то нужен еще firebird.msg

Говорю не умею так. Организационно это не допускаю.


Цитата:
ОС здесь совершенно ни при чем. В IBSurgeon обращались?

Поясню. Мы производим ПО и тестируем на определённом сервере. Мы в требованиях к ПО пишем что должно быть, Linux мы не подбирали и опции линукса не знаем. Один из клиентов нажал кнопку аналитики и было предупреждение что это будет долго. Проход за 5 лет по всем документам SQL процедурой с сохранением результатов. У клиента программа перестала реагировать и он просто вырубил приложение. После этого пропал коннект во всех кассах. Они не долго думая перезагрузили сервер Linux. Я думаю что вполне вероятно выдернули розетку и вставили. База легла. Техпотдержка забрала останки применила ядерные утилиты и востановила часть базы, но некоторые таблицы имели неправильный номер страницы базы. Мы пробовали хекс редактором исправить, но простите ламеров - не вышло. В итоге у клиента не обозначенное в лицензии ПО, у клиента расхождений по базе около сотни от дистрибутива. Они там сами чтото воротят. Это первый клиент на которого мы просто забили болт.
Автор: miwa
Дата сообщения: 22.03.2013 13:02
delover
Ну об чем и речь - ваш клиент полез туда не зная куда и напоролся на грабли. «Если пациент идиот, то это надолго»© и здесь нету ни вашей вины, ни вины линукса, ни ФБ.

А об организационном недопущении установки клиента рядом з бинарником - здесь вы правы и неправы одновременно. Правы в том, что штатная установка клиента на то и штатная, чтобы ее использовать по умолчанию. Но в случае, когда у клиента на одном компьютере кроме вашего софта есть еще какой-то, который тоже использует ФБ, и своей установкой перезапишет клиента из вашей установки, то... Виноватыми все равно сделают вас, потому что именно ваша программа не работает. Или же после установки вашей программы перестал работать любимый клиент-банк, или еще чего-то.
Автор: delover
Дата сообщения: 22.03.2013 18:36
miwa

Цитата:
на то и штатная

Вы правы. Повторюсь организационно решаемо, техподдержка справляется удачно, даже на разные порты вешает.

Того программера уволили, но техподдержка рассказывает смешное - они приняли такого же.) Жизнь не урегулировать - хотел пофилосовствовать, но мы ушли далеко от темы.
Автор: delover
Дата сообщения: 28.03.2013 19:32
Я тут почитал википедию, ухахатывался простите, но язык вполне научный чтобы детям рассказать сказку. Особо это привлекло.


Цитата:
В режиме управления копированием, напротив, не существует такого автоматического распространения обновлений. Копии данных создаются и управляются с помощью пакетного или фонового процесса, который отделён во времени от транзакций обновления.


В итоге, я наверно опять не шарю что такое репликация. Я знаю только связку ID источника + UID единственного источника + номер пакета.

Добавлено:
То есть я знаю только то что - стань общим только через один источник. Описанные в вики коллизии характерны для репликации фокспро.
Автор: miwa
Дата сообщения: 01.04.2013 15:14
delover
Не нашел ни одной смешной буквы в приведенном отрывке. Контекст хоть откуда? И при чем здесь ФБ?
Автор: delover
Дата сообщения: 02.04.2013 06:59
miwa
В Википедии слово репликация.


Цитата:
Не нашел ни одной смешной буквы

В контексте репликации рассматривается случай с двумя или несколькими версиями одних и тех же данных. Из баз данных заимствован термин транзакция изменений для описания подобного конфликта. Вполне практично для регулировки вводится дата изменений хотя сервера могут быть рассинхронизированы. Нужно это только для существования единого правила, - какие вы изменения учитываете в общем случае, так как в точку 2 могут так же прийти пакеты с изменениями. Транзакция подразумевает естественно пачку изменений. Теперь читая про фоновый процесс который отдалён во времени возникает предположение, что они имели ввиду примерно следующее - в первом часу я разгребаю что пришло в мою базу, во втором часу я фоного создаю копии из своей базы - транзакции разделены.

Ну и забавно, что не говорится о том, что во время "фонового копирования", так же могут происходить изменения копируемых данных - от этого всё равно никуда не денешся.
Автор: miwa
Дата сообщения: 03.04.2013 14:01
delover
Да, в контексте уже смешнее, согласен. Хотя репликация - тема вообще неблагодарная, хоть в Firebird хоть где угодно.

Я, кстати, не стал бы завязываться на дату-время при репликации (да и не завязываюсь, вообще-то). Идентификатор - он как-то надежнее.
Автор: delover
Дата сообщения: 03.04.2013 17:46
miwa

Цитата:
Хотя репликация - тема вообще неблагодарная

100% Требования к репликатору в квадрате выше.


Цитата:
хоть в Firebird хоть где угодно.

По моим понятиям ФБ очень богат в выборе транзакций, которые замечательно освещаны в прессе. Если бы я к комуто прислушивался в вопросе репликации то к файрбёрдовцам.


Цитата:
Я, кстати, не стал бы завязываться на дату-время при репликации (да и не завязываюсь, вообще-то). Идентификатор - он как-то надежнее.

Я иногда много не проговариваю. Понятие 2 версии одних и тех же данных, оно из репликации в понятии сетевого процесса а не локального переливания. Имеется ввиду был выдан идентичный уид или чтото какойто реплике. В точке А её изменили в точке Б её изменили, после этого центральный офис поимел оба изменения плюсом мог сам изменить. Этот пример неотьемлем от понятия реплика (в свете асинхронной репликации), вики почемуто его прибила. Важность примера несоизмерима, когда кроме центрального офиса есть ещё точка, где просто необходимы актуальные данные. Такое бывает не редко.

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

Добавлено:
Сори я опять наверно не договариваю, я делю данные на 3 вида (временные таблицы не учитываю).
1) Справочники, это то что выпрямляется даже с неопытным программистом.
2) Актуальные данные - это например документы - неплохо когда во всех точках имеется последний именно документ, но это не так важно - можно сослаться на плохой интернет.
3) Накопительные данные - представте на вашей электронной карте будут те суммы когда у вас деньги закончились. В этом случае не важны все тонкости операций с карточкой во всех точках - это избыточность - важна правильная сумма. Тут даты тоже не нужны.
Автор: delover
Дата сообщения: 04.04.2013 08:17
С Доменами какие-то косяки. Добавил поле с дефолтом которое не может быть null. Процедура сделала вставку и таблица не открывается. Залез в IBExpert. Вижу в колонке not null значение null. Этого я вообще не понял. Но понял что иногда домены не срабатывают и приходится исправлять в триггере.
Автор: romano501
Дата сообщения: 04.04.2013 11:37
delover
Ограничение not null не сработало не изза того что "иногда домены не срабатывают" а по иной причине. Если у домена стоит ограничение NOT NULL то во вменяемом состоятии неповредженная база не сможет его обойти. Видимо у тебя произошел какой-то глюк
Автор: delover
Дата сообщения: 04.04.2013 14:00
romano501
Наверно глюк. Вырубил триггер, вставляет нормально, но я перекомпилировал процедуры до этого. Возможно перекомпиляция исправила глюк.
Автор: miwa
Дата сообщения: 04.04.2013 15:48
delover
Дефолные значения не вставляются в случае, если клиент явно пишет в поле null. Тоесть если писать insert into tablename(f1, f2) values (1, null) то дефолт на поле f2 не сработает. Для случая insert into tablename(f1) values (1) в поле f2 будет проставлено дефолтное значение.

P.S. В доке это описано.
Автор: romano501
Дата сообщения: 04.04.2013 18:03
delover
Точно, про явный NULL забыл совсем. Просто в моих базах я не использую NULL вообще, за редким исключением.
Вот все и сходится, видимо у тебя где-то в коде подставляется NULL, пересмотри все места в программе, где ты вносишь запись в эту таблицу
Автор: delover
Дата сообщения: 04.04.2013 18:08
miwa
Да спасибо я это помню отлично, но я первый раз в жизни наблюдаю в колонке которая обязана быть не null значение null. В обычных условиях ФБ меня просто пошлёт нафиг со вставкой такой строки. Ну и мой собственный клиентдатасет никогда не даст этого сделать - он вызовет экзепшен в глубине стека у которого при выходе совершенно нет заглушек экзепшена. Тоесть в условиях когда не нарушена память и програма сможет опознать not null будет вылет с прелестями. Очевидно ФБ посложнее агрегат.

Добавлено:
Сомневаюсь я в нарушениях памяти у ФБ.

Добавлено:
да и во первых, давненько от когото уже слышал подобное всвязи с доменом. Во вторых буду себя считать счастливчиком что видел это.
Автор: miwa
Дата сообщения: 05.04.2013 09:14
delover

Цитата:
Да спасибо я это помню отлично, но я первый раз в жизни наблюдаю в колонке которая обязана быть не null значение null. В обычных условиях ФБ меня просто пошлёт нафиг со вставкой такой строки.

Значит, условия были необычными

И, да, согласен, было что-то с нуллами и доменами. Если найду/вспомню - отпишусь.
Автор: delover
Дата сообщения: 23.04.2013 18:44
Hello Ledi, Miledi, Gay and Man
Помогите плиз - не знаю как обрабатывать. У меня две транзакции меняют данные, последняя получает deadlock. И никакой уверенности что надо ждать и пробовать закоммитить дальше. У кого есть опыт.

Добавлено:
Просто когда после комичу - всё хоккей. Это очень интересное свойство.

Добавлено:
А дирики не читают?
Автор: miwa
Дата сообщения: 23.04.2013 23:29
delover
Цитируя букварь - пишущие транзакции должны быть максимально короткими. Ну а насчет того, что делать после дедлока - вам виднее. Если с двух компьютеров одновременно меняется один и тот же документ, или там элемент справочника - это скорее организационная проблема, а если у вас "остатки не идут", или подобные проблемы с агрегатами - так тут я бы вообще структуру базы менял.

Возвращаясь к вопросу - да, если после дедлока закоммитить транзакцию, то она перезапишет данные предыдущей транзакции. Вам решать, насколько такое поведение допустимо.
Автор: victor r
Дата сообщения: 24.04.2013 14:11

Цитата:

Добавлено:
Просто когда после комичу - всё хоккей. Это очень интересное свойство.

Вот как я делаю: если это два крупных расчета во времени около 1-5 минут и один из бухгалтеров ловит деадлок (что бывает крайне редко), то он просто выходит и через время запускает заново-всё гууд. Обычно этим занимаются не более двух начальников, и то из разных подразделений, так что пересечься с данными друг друга они не должны теоретически.
А если два субъекта редактируют один и тот же лицевой, транзакция запускается только после кнопки Ок (тут деадлок крайне редкая ситуация при менее 50 юзерах) и если все таки ошибка, то он видя её заходит и сам перепроверяет что не сохранилось, потому что юзер заинтересован в правильности занесенной информации.
Подитоживая я бы сказал: "не парься". Главное что бы в таких случаях ПО предупреждало о возможных не сохраненных данных и предлагало дальнейшие действия. Удачи.

Автор: delover
Дата сообщения: 25.04.2013 19:00
miwa
это скорее организационная проблема
Да это одновременная работа с репликацией центрального офиса.

victor r
транзакция запускается только после кнопки Ок
Спасибо действительно великолепная мысль, я ещё не экспериментировал.) Удачи.

miwa

Цитата:
ALTER SEQUENCE нельзя использовать внутри процедуры; это DDL а не DML. Да и временная процедура... Для этого же есть execute block.

Спасибо делаю закладку. Я вечно про это забываю - помогло.
Автор: mrUlugbek
Дата сообщения: 06.05.2013 07:31
Привет всем
Как удалить Interbase из системы полностью ..
Конфликтует с программой который сделано для Firebird 2.1


Добавлено:
При подключение
дает ошибку -923 isc_attach_database: connection rejected by remote interface
в сервисе отключил сервер Interbase..
Работает только Firebird//
Автор: exteris
Дата сообщения: 06.05.2013 08:01
mrUlugbek
В логах FB есть что-нибудь?
Автор: mrUlugbek
Дата сообщения: 06.05.2013 08:55
exteris
Там просто написано
starting: "C:\Program Files\Firebird\Firebird_2_5\bin\fbserver.exe"
Видимо проблема c Interbasе
я удалил оба сервера.. реестр почистил ccleanerom
установил занова.. Firebird последный 2.5.2
теперь ошибка -904 no activ connection//


Автор: exteris
Дата сообщения: 06.05.2013 11:50
С такой ошибкой не сталкивался.
Если программа сделана под версию 2.1, то возможно ей 2.1 и нужно, да еще и не на стандартном порту. Firebird ставится инсталлятором программы или отдельно? IBEXpert-ом получается к базе присоединиться?
И кто разработчик программы, может стоит к нему обратиться?
Автор: Andryshok
Дата сообщения: 06.05.2013 12:41
mrUlugbek Удали Firebird. Поищи в системе файлик gds32.dll и удали его. Далее находишь файлик c:\Program Files\Firebird\Firebird_2_1\aliases.conf - это алиасы баз, там есть пример в файле, прописываешь туда свою базу, перезапускаешь Firebird. Потом смотри в своей программе - там должна быть настройка подключения - прописываешь туда свой алиас. Должно работать.
Ошибка та что он пишет - это значит что нет БД к которой он пытается подключится. И если у тебя прога использует Firebird 2.1 не нужно ставить 2,5 . Если ничего не получится ставь тимвьювер и отпиши адрес в личку - разрулим
Автор: mrUlugbek
Дата сообщения: 06.05.2013 13:34
Получился
спасибо всем
удалил все полностью
System32/
SystemWOW / удалил GDS32 FBclient IBxml IBclient64
реестр искал Interbase тоже удалил
рестартанул
поставил занова
FIrebird 2.5.2
работает .. ура ура

Страницы: 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465

Предыдущая тема: Сравнение двух строк


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.