Kirill Temnenkov wrote:
@echo off
set reg_path=HKEY_LOCAL_MACHINE\SOFTWARE\Firebird Project\Firebird
Server\Instances
set reg_param=DefaultInstance
for /f "tokens=1,2,*" %%a in ('reg query "%reg_path%" /v
"%reg_param%"') do if "%%a"=="%reg_param%" set reg_value=%%c
echo "%reg_value%"
pause
Ovchinnikov Vasily wrote:
Кури утилиту REG
C:\>reg QUERY "HKLM\SOFTWARE\Firebird Project\Firebird Server\Instances" /v
DefaultInstance
HKEY_LOCAL_MACHINE\SOFTWARE\Firebird Project\Firebird Server\Instances
DefaultInstanceREG_SZC:\Program Files\Firebird\Firebird_1_5\
Результат ее
Может кто уже решал подобную задачу? Нужно сделать bat файл, который бы
интенсивно использовал утилиты fb из каталога bin. Причём без участия
узера. Проблема в том, что пути нет в PATH и ничего не работает. Если
способ извлечь в батник пусть из реестра?
Ещё вопросик. Есть ли способ вызывать is
Пока возникло серьёзное подозрение на слубжу восстановление системы. Она
включена и в файле filelist.xml было расширение gdb. Вероятно эта слубжа
раз в сутки блокировала файл БД для создания точки восстановления...
Vlad Khorsun wrote:
У винды есть perfmon, который ты конечно же настроил и изучаешь логи
в моменты торможения...
Пока не могу, т.к. управляю этим сервером по эл. почте.
Нужно составить текстовую инструкцию админу широкого профиля по
настройке этого перфмона...
Может какие службы у винды есть типа дефрагметатора/индексатора?
Кстати, расширение файла gdb. Может оно влияет?
Arioch wrote:
какое-нибудь обновление антивируса/файрвола, которое на 20 секунд
блокирует TCP/IP ?
Период чуть больше 24 часов. Инета там нет.
Khorsun Vlad wrote:
Памяти 2Гб, диск один SATA2. Но и база то мелкая, зато реалтайм.
Если ты хочешь кешировать БД целиком, то по памяти ты на грани. Добавить
её не помешает. Если реалтайм, то почему авто-свип не запрещён ? Далее.
Кэшировать всю особо не нужно, т.к. интенсивно юзается инф
Khorsun Vlad wrote:
Виноват оказался sweep.
Откуда это видно ?
Сорри, тут я ступил, посмотрел на next
OIT застревает или от роллбека, или от лимбо. Это азы.
Но в данном случае я не вижу застрявшего OIT, ибо OAT = OIT + 1, т.е.
есть долгоиграющая тр-ция с номером 67773711. С ней и раз
Alexey Popov wrote:
Как вижно разница скоро достигнет 2 и сработает sweep. Почему
транзацкции застревают - это отдельный вопрос, ранее такого не было.
Может быть rollback виноват???
Получается что после sweep разница обнуляется продолжается сразу расти
вновь? Что это может значить?
Ранее я писал:
Есть БД под FB2.0.3 SS. С ней постоянно работают несколько служебных
программ и периодически пользователи. В служебных программах
происходят только простейшие select/insert, которые выполняются
обычно мгновенно. Там так же сделана сигнализация (вывод в лог) если
какой то запрос бу
Alexey Popov wrote:
Есть FB2.0 SS и служба работающая на этом же компе. Служба подписывается
на события и слушает их. Всё это работает много дней. В какой то момент
перестают доходить события до службы. Для проверки этой гипотезы сделано
тестовое событие, которые регулярно по таймеру
Vlad Khorsun wrote:
В логе клиента, скорее всего, будет сообщение об обрыве коннекта.
Не проверял.
1. А что клиент пишет что то в лог?
2. Если он просто лежит в system, то куда уйдёт лог?
Всётаки остаётся неясным вопрос о том как себя ведёт асинхронное
уведомление о событиях если по каким либо причинам соединение для
событий накрылось. Возможна ли передача ошибки потребителю?
Oleg Matveyev wrote:
После переноса сервиса на сервер БД конфиг (приложения) остался прежним,
и строка коннекта была в виде 192.168.x.x:base
При отключении питания коммутатора - такой коннект отваливался.
Ого, спасибо, ценная информация! У меня тоже IP используется внешний!
Но у меня БД-шный к
Oleg Matveyev wrote:
Клиент и база у тебя на одном компе?
Теперь на одном.
И всёравно события отваливаются ?
Oleg Matveyev wrote:
Есть такая проблема, причем и на 2.0.6
Аналогично - висит служба, которая до получения события не делает ничего.
Но очень желательно не пропускать ни одного события, потому что при
получении - надо сделать вычисления и положить в БД результат.
Правда, у меня в качестве кли
Arioch wrote:
1) даже в этом случае, чем дальше, тем больше вероятность, что уже
случилось
2) запусти, действительно, регулярно повторяющийся ивент. При каком-то
постоянно происходящем запросе, чтобы раз в несколько минут посылался.
Перестал посылаться - значит пора переподключаться.
Так
Khorsun Vlad wrote:
Тогда чего же ты хочешь ? Чтобы оно само прошло ? :-D
Может косяк ещё где... Может даже и в клиенте.
PS Ты багу-то хоть в трекере нашёл ? А искал ?
Нотах смотрел - похожего ничего нет.
PPS Я не искал. Но с ивентами многое исправлялось.
Так может лучше на 2.1 пере
Khorsun Vlad wrote:
Такая есть. Но есть и 2.0.6, в которой что-то могло быть исправлено.
Есть релизноты и трекер для поиска этого чего-то.
На круглосуточной боевой базе стрёмно как то обновление делать.
Проблема наблюдается на одном инстансе из многих.
Arioch wrote:
а тупо раз в сутки переподключаться? ;-)
Если это накапливающаяся проблема.
Если же это происходит случайно, то не поможет.
запусть какой-нибудь дампер и посмотреть
1) какие есть соедuнения между службой и сервером
2) что по ним проходит, насколько помню для событий зaводили от
Khorsun Vlad wrote:
Есть FB2.0
Нет такой версии
А вот и есть! 2.0.3.12981
Есть FB2.0 SS и служба работающая на этом же компе. Служба подписывается
на события и слушает их. Всё это работает много дней. В какой то момент
перестают доходить события до службы. Для проверки этой гипотезы сделано
тестовое событие, которые регулярно по таймеру генерируется самой
службой и о
Khorsun Vlad wrote:
Я бы начал с настройки PerfMon'а и сопоставления его логов.
Свип можно отследить, мониторя OIT и OAT.
Кто бы написал тулзу, которая отображает разницу между OIT и OAT в
perfmon :).
Я просто вот думаю: sweep конечно тозмозит всех, но не настолько же.
Есть конечно вероя
Есть БД под FB2.0 SS. С ней постоянно работают несколько служебных
программ и периодически пользователи.
В служебных программах происходят только простейшие select/insert,
которые выполняются обычно мгновенно. Там так же сделана сигнализация
(вывод в лог) если какой то запрос будет выполняться с
Vlad Khorsun wrote:
Потому что ты ещё и хочешь потоковый анализ показаний делать,
насколько я
понял. Т.е. кто-то должен держать в памяти последние N показаний, и
*быстро*
реагировать на резкие их изменения.
Быстро не значит мгновенно. Есть критерии, логика которых затрагивает
измерения н
Khorsun Vlad wrote:
Если тебе нужно отражать показания сотен датчиков *немедленно*, то
никакая
СУБД тебе не подойдёт.
Это ещё почему? Вполне быстро можно выбрать 100 последных записей по
индексу. Минимальный уровень латентности не реалтаймовский, но и 10сек
это много. Все показания отобр
Khorsun Vlad wrote:
Во-первых *а*приори. Во-вторых - писать из датчика напрямую в БД
это и есть через жопу. Впрочем я выше написал что такое не лечу :)
Буфер есть, но только для нештатных ситуаций.
Я так и не понял, как ты предлагаешь вставлять записи, идущие от датчика
например раз в 1 се
Yurij wrote:
Если не писать напрямую с датчика в базу - все равно нужны будут
какие-то пляски с бубном насчет "получить отчет по данным, которые
еще в базу не попали".
Не просто отчёты, а поиск в реальном времени нештатных и особых ситуаций.
Впрочем, я скидываю такие данные в базу одной тран
Vlad Khorsun wrote:
Не, экономить номера транзакций тут нет никакого желания.
Если ты собрался каждое показание сохранять в отдельной тр-ции, то я
такое не лечу,
это в другое учреждение :)
А зачем оприори делать через жопу? Если датчик допустим даёт показания
раз в 10 сек (или даже туп
Yurij wrote:
Там есть печаль с такими данными, связанная с
равномерным приходом данных по времени и индексам.
Если выбирать данные по одному датчику по индексу,
то оно читает примерно так "одна запись из таблицы -
одно чтение страницы данных". Потому что на этой странице
все остальные записи
Vlad Khorsun wrote:
Предел в 2 миллиарда транзакций непреодолим.
Ну так не надо в него стучаться лбом - это больно и не нужно :)
Не, экономить номера транзакций тут нет никакого желания.
В 3-ке сделаем 4млрд. Потом посмотрим на возможность дальнейшего
расширения этого лимита.
Это уже
Vlad Khorsun wrote:
Предел номера транзакции,
Причём тут "такие объёмы" ???
Предел в 2 миллиарда транзакций непреодолим.
Остальные утверждения были больше вопросами
не 100% заполнение страниц данными,
Это к dbf\csv\txt - там 100%.
Если в базу делается только insert и select, то
Yurij wrote:
Такое чувство что не взлетит на FB.
На весьма хорошем железе взлетит и на FB, имхо.
Вопрос не только в железе. Больше к алгоритмам работы FB которые мало
оптимизированы на такие объёмы. Предел номера транзакции, скорость
prepare, размер TIP и PIP, глубина индексов, не 100% зап
Есть такая задача. Нужно хранить N лет, показания M датчиков на K
объектах с дискретностью P секунд. Оценки показывают что надо хранить
порядка 10 миллиардов показаний (FLOAT).
Таблица измерений (без PK)
Время, ID датчика, значение
Индекс по времени desc.
Полезен ли будет индекс по датчику (сел
Dmitri Kuzmenko wrote:
тюнить ФБ можно мало куда. И я говорю про конфигурации железа для СУБД
вообще. ФБ - одна из множества других СУБД.
Сейчас прибегут из "множества других СУБД" и будут вещать про
партиционирование и лог транзакций.
"Железо для СУБД" для среднестатитического админа ни о
Sergey Mereutsa wrote:
А что, кеш в 4 гига выставить для большой БД никак?
А интересно, кто пробовал такое делать?
Я, когда суперклассик ковырял. Работало, но сам суперклассик тогда
сырой был, пришлось ставить классик.
Вопрос то про суперсервер был. Суперклассик это совсем другое.
Dmitry Yemanov wrote:
А что, кеш в 4 гига выставить для большой БД никак?
А интересно, кто пробовал такое делать?
Dmitri Kuzmenko wrote:
Можно ли FW отключать или лучше оставить?
отключать можно, если это ФБ 2.1 и выше (см. firebird.conf)
Костыль однако. Но тем не менее...
или если
стоит raid с батарейкой. Но на raid с батарейкой может оказаться все
равно, Fw=on или off. зависит от крутизны raid.
Dmitri Kuzmenko wrote:
Время идет, рекомендации меняются. :-)
- система - на отдельном винте
- temp, база - можно на одном RAID 5 или 10
- бэкапы - на отдельном винте
В целях экономии можно бэкап наверное делать на системный винт, а оттуда
уже сливать по сети в надёжное место.
Dmitri Kuzmenko wrote:
можно я риторический вопрос задам, в пространство?
Поскольку ситуация с "выбором железа" у людей, работающих с ФБ,
просто ну никуда, не могу понять. Неужели эти люди
никогда не интересовались скоростью работы диска?
Не запускали HDTune? Не читали никаких обзоров про сравн
Sergey Mereutsa wrote:
Если система ушла в своп - то где бы он не располагался - настаёт она
самая - ж.о.п.а. Поэтому, пусть лучше памяти будет много.
Своп вроде бы всегда используется виндой для своих нужд.
Тогда кэша страниц побольше, 64-битные сборки хорошо память жрать
умеют :0)
Кстат
Sergey Mereutsa wrote:
Рекомендации от экстремалов:
1) Система на SSD, своп нафиг. Взять 2 SSD и на втором держать
отстающую копию системы (как сие сделать на винде - понятия не
имею).
А смысл тут в SSD? На сервере чтение с системого диска не особо часто.
Вот что делать со свопом?
4)
Владимир Аксенов wrote:
Классические рекомендации:
- система - на отдельном винте
- TEMP - на отдельном винте
Темп и систему почему бы не одном в целях экономии? Тем более что
большой нагрузки на темп не будет.
Никогда ещё не занимался комплектованием сервера для FB. Подскажите
кое какие моменты.
Планируется поставить простой зеркальный райд под базу.
Вопрос, надо ли ставить отдельный диск для системы, или тупо можно всё
свалить на массив? Других на нагрузок кроме FB не будет.
Если памяти в принцип
Vlad Khorsun wrote:
Да. Но это не связано с размером таблицы. Можно и на маленькой
таблице получить
большие тормоза при вставке - просто создав десятки индексов с длинными
ключами.
Вопрос то в рависимости от размера таблицы. Ведь она в любом случае
должна быть логарифмической.
PS Размер
Михаил Викторович wrote:
Кто же их упомнит. Несколько десятков определенных вручную планов.
Ручные ещё не значит хорошие.
Вставка как вставка обычная где то в три-четыре таблицы, что про нее еще
можно сказать я не знаю.
Индексов штук 8-10 в каждой таблице. При активной работе 400-650 человек
Михаил Викторович wrote:
Т.е. анализ планов запросов ниасилили?
Ну разве мы могли об этом сами догадаться? Спасибо вы сейчас посеяли в нас
столь исключительную своей оригинальностью мысль. :)
Тогда хотелось бы услышать о выявленных узких местах в вашей ситуации.
На самом деле есть опредлённ
Михаил Викторович wrote:
Я написал свое мнение о том, что человек прав, придя к идее архива.
Это плохая идея.
Если уж делать ахрив, то создавая копию базы на на какой то момент времени.
В одном из проектов мы использовали архивные таблицы в той же базе. Конечно
время бакапа растет, но пока
A K wrote:
Реальная ситуация. Большая база на большом предприятии. Работает
медленно. Идея: делаем архивную БД и оперативную, в которой держим
последние год-полтора.
Это ничего почти не даст. Если запросы используют только данные за
последнее время, то размер таблиц фактически не влияет за
Dmitry Yemanov wrote:
Если смотреть на SQL, то это типичный DSL. Но неплохо бы добавить
возможность определять локальные иммутабельные переменные-множества типа:
x=select * from table
select * from x;
Это существенно упростит декомпозицию многоэтажных запросов и улучшит
читабельность.
Ну и че
Dmitry Yemanov wrote:
1) Внутрь сервера яву никто не тянет, там лишь интерфейс к ней.
Остальное снаружи в плагинах. Опционально.
Это вопрос технический - где будет работать JVM.
Однако тенденция неприятная.
2) Нормальный суперсервер есть в той же версии, что и ненавистная тебе
ява. Если ты х
Vlad Khorsun wrote:
Я не собираюсь продолжать эту беседу ибо она была спровоцированна с
единственной целью - поржать в ЖЖ над частично процитированным и оторванным
от контекста моим частным мнением. Выставляя косным идиотом не только
меня (на
это мне наплевать), но и Firebird вместе со всем
Arioch wrote:
ну в высоконагруженных сильнопараллельных программах оно существует уже
не год-три,
Там рулят в основном C++, фортран и кобол. Увы.
Erlang и написанные под его влиянием библиотеки.
Erlang это прежде всего узкоспециализированный RTL, язык там дело десятое.
Yurij wrote:
А как вы относитесь к функциональному программированию и около него
вообще?
Функциональное это слишком широкий термин. Функционально можно и на
голом C писать.
Если смотреть на SQL, то это типичный DSL. Но неплохо бы добавить
возможность определять локальные иммутабельные пер
PEAKTOP wrote:
Допустим есть комп в инете со статическим IP. Мы подключаемся, все
нормально, РСУБД (распределенная СУБД) прекрасно работает.
Проходит время и филиал эволюционирует в укрупненное подразделение
(типа, становиться "сержантом" и у него уже свои подчиненные филиалы).
Ставим внутре
Dmitry Lendel wrote:
Разница простая - нормальный полноценный суперсервер неасилили и
Что ты имеешь ввиду под полноценным супером?
SMP софт с общим кэшем и минимальными издержками на взаимоблокировки.
Кстати у IB вроде сделан был такой.
получился уродец - суперклассик, который почти как на
Dmitry Lendel wrote:
Я прошу прощения за бестолковость. Я не могу никак понять разницу между
суперклассик и супер.
Можно мне объяснить на пальцах?
Разница простая - нормальный полноценный суперсервер неасилили и
получился уродец - суперклассик, который почти как настоящий суперсервер
но жрё
ÐндÑей ÐÑÑÑинин wrote:
Рданном ÑлÑÑае инÑеÑеÑÑÐµÑ ÐºÐ°ÐºÐ¾Ðµ-Ñо знаÑение коÑоÑое ÑвлÑеÑÑÑ ÑникалÑнÑм
Ð´Ð»Ñ Ð±Ð°Ð·Ñ Ð² глобалÑном ÑмÑÑле :-) ÐÐ¾Ð½Ð¸Ð¼Ð°Ñ ÑÑо ÑÑеб Ð¼Ð¾Ð¶ÐµÑ Ð±ÑÑÑ, но Ñем н
База ещё из под FB1.0, ODS 10.0
При попытке работы с ней под FB2.1, при попытке выполнить простой insert
получается странная ошибка
invalid request BLR at offset 11
column is not defined in table
после перевода на ODS 11.0 работает нормально.
Есть ли какой способ обойти проблему оста
Андрей Кручинин wrote:
Кстати, вопрос по теме - корректно узнавать размер БЛОБа через char_length?
может тогда через OCTET_LENGTH?
А вообще в api есть функция isc_blob_info которая выдаёт размер блоба.
Dmitry Yemanov wrote:
Сначала ID, если не равны, то содержимое (кусками по 1КБ, выход по
первому неравенству).
Логично. Только предварительно можно размер ещё сравнить, если он
легкодоступен.
В принципе тормоза будут только если обновлять тождественным значением,
что маловероятно.
ЗЫ. это
Нужно узнать изменилось ли блоб-поле в триггере. Если написать
if(new.blob_field != old.blob_field) then ...
То что будет реально сравниваться? blob_id или побайтно содержимое?
В ib помню что сравнивались id.
Если побайтно, то значит тормоза на больших блобах?
Nikolay Ponomarenko wrote:
ÐеÑиÑÑÑ Ñем, ÑÑо ÑкÑÐ¸Ð¿Ñ ÑÐ¾Ð·Ð´Ð°Ð½Ð¸Ñ Ð±Ð°Ð·Ñ ÑазбавлÑеÑÑÑ ÑеконнекÑами - поÑле
каждой веÑÑии вÑÑавлÑеÑÑÑ
ÐÑо давнÑÑ Ð±Ð¾Ð»ÐµÐ·Ð½Ñ. У Ð¼ÐµÐ½Ñ Ð¿Ð¾Ð´Ð¾Ð±Ð½Ð°Ñ Ð¾Ð±Ð½Ð¾Ð²Ð»Ñлка
Dmitry Lendel wrote:
Стандартный инсталятор при указании установки только клиента делает всё
аналогично инсталяции сервера, только не все файлы ставит.
В смысле? Чего он не ставит?
Файлы сервера.
Просто кинуть fbclient.dll в system32 нельзя ибо он не найдёт свои файлы
без ключа в реестре. Д
Dmitri Kuzmenko wrote:
Hello, Alexey!
Alexey Popov wrote:
Одного fbclient.dll недостаточно. Ему надо ещё firebird.msg и ещё какая
то левая dll, плюс рантайм от VC.
Просто кинуть fbclient.dll в system32 нельзя ибо он не найдёт свои файлы
без ключа в реестре. Да и MS уже не рекомендует
Dmitry Beloshistov wrote:
Православный способ -грузить fbclient.dll из Firebird\bin.
У пользователей установлен сервер? А нафига, если в минимальном
случае достаточно fbclient.dll?
Стандартный инсталятор при указании установки только клиента делает всё
аналогично инсталяции сервера, только н
По старинке софт юзает gds32.dll из каталога system32 винды.
Вроде бы этот метод устаревает.
Православный способ -грузить fbclient.dll из Firebird\bin.
Но обычно этого пути нет PATH, да и не нужен он там.
Поэтому софт должен делать LoadLibrary("fbclient.dll") с точным путём.
(Статическая линковка
Пока отбой тревоги. Добавил логов, оказывается параметр запроса почему
то внезапно стал чрезмено большим. Глюк в где то в другом месте.
Dmitry Yemanov wrote:
Тип или длина параметра в SQLDA не совпадает с типом/длиной колонки.
Убрал глючный запрос с параметром. Стало выдовать аналогичную ошибку в
другом месте. Комп этот к сожалению не имею под рукой. Только
дистанционно. Говорят до сегодняшего времени всё работало на этом к
С одного из клиентский компов при работе с базой на одном и том же
запросе вылетает ошибка:
Incompatible column/host variable data type
Dynamic SQL Error
SQL error code= -303.
arithmetic exception, numeric overflow, or string truncation
Со всех других клиентских компов всё работает нормально! В
Михаил Викторович wrote:
А
бизнес аналитиков их просто нет!
+1 Грамотный аналитик обеспечит себя работой на всю жизнь не обременяя
себя ковырянием в коде.
Dmitry Yemanov wrote:
У операционки кончились ресурсы в тот момент, когда сервер откатывал
операцию или транзакцию.
Интересно тогда зачем TIP нужен?
Kochmin Alexandr wrote:
кому то надо было проектировать ПО нормально. и учитывать нестабильный
канал.
Протокол TCP плохо себя ведёт на плохих каналах. Плюс его толком не
подкрутить. Кастомные протоколы позволили бы легко решать такие задачи.
Andrei wrote:
2) на стороне клиента (fbclient.dll). Предусмотреть функцию настройки
с тремя параметрами:
-- время ожидания восстановления соедиенения
-- период попыток повторного подключения
-- call back функция
Это всё слишком узко. Кардинальное решение - это возможность подсовывать
sasha wrote:
Интересно, насколько Delphi популярен ещё?
На BCB5 проекты живут у нас. Портировать на высшие версии уже поздно.
Ну я это всё к чему. К тому, что не достаточно иметь хороший сервер.
Нужны также и качественные библиотеки доступа к этому хорошему серверу.
Недавно был флуд на э
Игорь Горбонос wrote:
И чесно говоря я не понимаю, почему нельзя сделать для себя модуль,
который будет асинхронно выполняить запросы к БД, если есть такая
необходимость?
И как будет выглядеть этот модуль? Который должен быть универсальным.
Он не может вернуть курсор в другой поток, т. к.
Khorsun Vlad wrote:
Ну написать клиента на какую либо платформу.
Каких платформ тебе не хватает ? Где *масса* применений ?
Как ты думаешь, почему ява и нет клиенты не хотят использовать gds32.dll
и ходят напрямую по сокетам? Почему? Зачем им этот секс?
Сейчас эти клиенты на птичьих пр
Sergey Mereutsa wrote:
Так вот. Асинхронность, скажу я вам, штука зело вкусная, ежели её
применять правильно. Особенно, когда у тебя работа с девайсом, у
которого на борту 4 войсовых процессора и 30 войсовых каналов, которые
ты в цикле опрашиваешь и вся работа с которыми - это работа с
событиями
Khorsun Vlad wrote:
Применений масса.
Да ну ? Где ?
Ну написать клиента на какую либо платформу.
Я уже давно плачу что необходимо асинхронное взаимодействие с сервером.
Кому нужно ? Почему ты один об этом плачешь ?
Меня можно считать за десятерых :)
Не надо идти на поводу у больш
Khorsun Vlad wrote:
Я же вижу ситуацию так - *он хочет* непонятно чего и зачем,
Применений масса. Я уже давно плачу что необходимо асинхронное
взаимодействие с сервером. Чтобы поток не тупо ждал ответа сервера в
блокирующем режиме, а мог в это время заниматься другими делами.
Допиливать
Khorsun Vlad wrote:
Про транспорт это другая, более далёкая, хотелка.
Так ты же с неё начал ?
В изначальном сообщении я высказал две мысли:
1) Доступ к серверу по сокетам.
2) Возможность указывать свой транспорт для gds32.dll
Нельзя ли в одной теме обсуждать ОДНУ вещь ?
Ну уж если оч
Khorsun Vlad wrote:
И где тут "свой транспорт" ???
Про транспорт это другая, более далёкая, хотелка.
Это годится только для приложения вроде "hello firebird".
Это только пример, реализовав который можно постепенно доработать
функционал до желаемого уровня.
Описание всех пакет
Yurij wrote:
Имхо, проще рядом с FB поставить веб-сервис и завернуть всю бизнес-
логику в него, уж по HTTP с экзотических платформ ходить намного
проще, нежели реализовывать stateful протокол на всех мыслимых и
немыслимых вариациях железа и ОС.
3х звенку городить может быть не проще. Особенно
Dmitri Kuzmenko wrote:
возьми исходники клиента .Net или JayBird и посмотри.
Дык первого я и смотрел. Не в о том речь. Речь о написании клиентов на
всяких экзотических платформах коих сейчас расплодилось немерянно.
Ковырять левые сорцы юзающие недокументированные фичи - это не
продуктивно.
Khorsun Vlad wrote:
Диалог не получился... или ты меня не слышишь, или я тебя не понимаю.
Попробуем разжевать ещё раз. Предположим у нас есть некая
гипотетическая платформа, которая имеет доступ в сеть по TCP. На другом
компе крутится FB и слушает порт 3050. Надо сделать следующие вещи:
Khorsun Vlad wrote:
Почитай src/remote/interface.cpp и src/jrd/why.cpp. На пальцах - клиент
поддерживает свои списки аттачей\тр-ций\запросов\курсоров\блобов, кеширует
результаты выборки, поддерживает представление XSQLDA\XSQLVAR и т.п.
Дык и что? Ясное дело что имеем сильно stateful прото
Khorsun Vlad wrote:
Тут всего то надо нормально специфицировать транспортный протокол на
уровне сокета.
Протокол - и всё ? Ты или оптимист, или бла-бла-бол :)
Давай конкретнее. Например, net клиент юзает напрямую сокет. При этом он
придерживается некоторого протокола. Так?
Что ещё надо
Dmitry Lendel wrote:
Про спонсора. Я, примером, не потяну по деньгам такую разработку, но
могу внести лепту в общий котел в размере 1000 USD налом и раза в три
больше безналом с НДС в грн. В девиз "давайте скинемся" я не верю. Тут
нужно находить заинтересованных. Один есть . :-))
Тут всего т
Taras Kucher wrote:
http://www.ibase.ru/dataguard.html
http://www.slideshare.net/ibsurgeon/fbdataguard-1-2901922
http://www.slideshare.net/ibsurgeon/firebird-dataguard-in-russian-2735788
Ничего не понятно :(
Можно ссылку где конкретно написано что она конкрентно умеет делать и какой
алгоритм её работы.
Dmitri Kuzmenko wrote:
Большинство баз лечится изменением пары байт в нужном месте.
да-да, конечно. Что-то я таких повреждений баз и не припомню.
Имеется ввиду чтобы FB начал читать её без ошибок. А потом конечно ручками
допиливать пока b/r не пройдёт.
Чаще всего бывают у меня wrong page
Dmitri Kuzmenko wrote:
и еще хочу добавить, что нефиг базы лечить :-)
надо их защищать FBDataGuard-ом.
Т.е. пора перестать бороться со следствием, и начать бороться с причиной.
Скрытая реклама detected!
Базы ломаются по причинам: сбоев питания, глюков ОС, рукоблудство юзеров и
т. п. Такое
Dmitri Kuzmenko wrote:
пусть лежит. Зато мы не даем гранату в руки неопытным пользователям.
как раз убрали после нескольких поломок баз вот таким образом.
Ну если у кого хватило ума ковырять живую базу без резевной копии?
Остальные то тут причём?
Поэтому без понимания этих структур "ручно
Dmitri Kuzmenko wrote:
Была удобная утилита IBSurgeon Viewer. Последняя найденная версия 1.0.2
На офф. сайте её вообще нет.
давно убрали.
А зачем? Теперь она лежит на куче левых сайтов.
Утилита удобна для ручного лечения битых баз.
Больше не развивается?
нет, ибо без надобности. А вопро
Была удобная утилита IBSurgeon Viewer. Последняя найденная версия 1.0.2
На офф. сайте её вообще нет.
Больше не развивается?
Игорь Горбонос wrote:
Спасибо, но по моему я имел в виду похожую статью, в которой акцент
делался на описание приемов навигации, т.е. "тривиальные" моменты:
- фетчь не всего набора, а только записей для грида + небольшой запас;
- при кардинальных перемещениях из начала в конец - не фетчить вс
Khorsun Vlad wrote:
Ð ÑÑ Ñ
оÑеÑÑ, ÑÑÐ¾Ð±Ñ ÑÐµÐ±Ñ ÑÑÑ Ð½Ðµ пинали ? ÐÑбиÑай Ñлова и помни, ÑÑо ÑвоÑ
мнение не обÑзаÑелÑно пÑавилÑное мнение.
ХоÑеÑÑ Ð¾Ð± ÑÑом поговоÑиÑÑ? Ðавай. Я ÑÑи
Dmitri Kuzmenko wrote:
?
- по умолчанию write
- для ro надо явно указывать read
Да, я же забыл что тут всё через жо.
Флаг isc_tpb_write по сути не нужен.
Вообщем с явным параметром read тоже самое.
To unsubscribe from this group, send email to ru-firebird+unsubscribegooglegroups.com or
r
Dmitry Yemanov wrote:
напÑимеÑ, еÑли ÐºÐ¾Ð½Ð½ÐµÐºÑ Ð½Ðµ обÑаÑаеÑÑÑ Ð·Ð° current_connection, Ñо
вÑдаваемÑй Ð½Ð¾Ð¼ÐµÑ Ð½Ðµ ÑвелиÑиваеÑÑÑ.
Уже давно ÑвелиÑиваеÑÑÑ.
ÐÐµÐ½Ñ ÐºÐ°Ðº Ñо Ñаз за ÑÑо ÑÑÑÑ Ð½Ð¾Ð³Ð°Ð¼Ð
Результаты 1 - 100 из 607 matches
Mail list logo