29.09.2011 14:02, Arioch пишет:
В письме от Thu, 29 Sep 2011 05:44:30 +0400, Андрей Кручинин
an...@bk.ru сообщал:
3. Флажок полученный новой аналитикой делается активным (ну типа
заносится в генератор :-) )
инетресно, может ли оптимизатор эффективно обрабатывать select с
отсылкой к
В письме от Thu, 29 Sep 2011 16:55:53 +0400, Андрей Кручинин
an...@bk.ru сообщал:
А зачем? Я формирую текст запроса, и в него заношу заранее считанное
...
Можно и таблицу конечно, но я тут разницы не вижу принципиальной где
хранить.
Ну... таблица позволяет не формировать текст запроса
28.09.2011 2:07, Arioch пишет:
В письме от Tue, 27 Sep 2011 17:26:15 +0400, Андрей Кручинин
an...@bk.ru сообщал:
Домучал.
Собственно скрестил разные методы - скорость поехала. Мож кому и
пригодиться :-) Но тут имеет место то что аналитика делается по
покупателям, это важно.
1. Готовится
В письме от Fri, 23 Sep 2011 21:41:58 +0400, Андрей Кручинин
an...@bk.ru сообщал:
Аналитика ЕЖЕДНЕВНАЯ, в пиковое время работы должна отрабатывать. В этом
то и загвоздка собственно. Если бы было можно ночью делать - тут даже
а нельзя как в графике рисуют на невидимой странице, а потом на
27.09.2011 16:44, Arioch пишет:
Аналитика ЕЖЕДНЕВНАЯ, в пиковое время работы должна отрабатывать. В
этом то и загвоздка собственно. Если бы было можно ночью делать - тут
даже
а нельзя как в графике рисуют на невидимой странице, а потом на неё
переключают?
есть некоторое состояние, БД без
В письме от Tue, 27 Sep 2011 17:26:15 +0400, Андрей Кручинин
an...@bk.ru сообщал:
Ну я так и хотел, но есть засада типа - кода то достаточно. И указаний
тех же таблиц много.
ну так если дублировать (вернее даже две с половиной копии делать) всю БД,
то это много места на диске займёт, а
Юрий пишет:
Быстрее всего и удобно автоматизировать если:
1. удаляем старую внешнюю таблицу
2. смотрим структуру таблицы в базе, создаем аналогичную внешнюю
3. выкачиваем данные во внешнюю таблицу, удаляем таблицу
IMHO если структура не меняется, не надо ни удалять, ни создавать.
После
26.09.2011 13:52, Igor Zakhrebetkov пишет:
Юрий пишет:
После расконнекчивания с БД файл внешней таблицы можно просто очистить.
Это как?
--
Андрей Кручинин
г) заливка происходит в неактуальную таблицу, в которой отключаются
индексы и триггеры и делается сборка мусора
Я что-то подобное и имел ввиду, когда писал про временную таблицу.
Дмитрий
Здравствуйте.
Ежемесячно нужно переносить данные между несколькими удаленными
базами. От одной большой БД на могучем сервере на удаленные сервера,
которые слабее.
Данные это таблица с 10-ом млн. записей.
Быстрее всего и удобно автоматизировать если:
1. удаляем старую внешнюю таблицу
2. смотрим
26.09.2011 0:47, Юрий пишет:
Здравствуйте.
Ежемесячно нужно переносить данные между несколькими удаленными
базами. От одной большой БД на могучем сервере на удаленные сервера,
которые слабее.
Данные это таблица с 10-ом млн. записей.
Я это ежедневно делаю :-) По нескольку раз в день.
Быстрее
23.09.2011 9:29, Dmitry Lendel пишет:
А если во временную таблицу заливать, а потом insert or update?
Дмитрий
А чем в данном конкретном случае временная будет отличаться от внешней?
Проблема то не в том что данные неоткуда брать, при заливке сначала
удаляются данные, потом заливаются заново.
Андрей Кручинин ...
Хотя, пока писал пришла бешеная мысль в голову :-) Сделать запрос через ХП, в которой определять откуда забирать данные. А уж
метку откуда можно и в генераторе держать.
Можно и так. Или научить программу пользоваться актуальной таблицей.
Чтобы не замучать сервер
Процесс надо делать 3-4 раза в день в идеале (минимум 2 раза), причем
гарантированно в этот момент юзвери могут полезть в этот момент с
запросами. А отсутствие индексов просто уложит сервер на выборках. Там 10
млн где-то записей с выборками по двум int полям.
так обычно заливают warehouse для
23.09.2011 20:38, Oleg Matveyev пишет:
Процесс надо делать 3-4 раза в день в идеале (минимум 2 раза), причем
гарантированно в этот момент юзвери могут полезть в этот момент с
запросами. А отсутствие индексов просто уложит сервер на выборках. Там
10 млн где-то записей с выборками по двум int
23.09.2011 13:27, Khorsun Vlad пишет:
Андрей Кручинин ...
Хотя, пока писал пришла бешеная мысль в голову :-) Сделать запрос
через ХП, в которой определять откуда забирать данные. А уж метку
откуда можно и в генераторе держать.
Можно и так. Или научить программу пользоваться актуальной
10 млн - данные за один день :-) И только за 3 региона, а в планах
поболее. Фармрынок очень быстро меняется :-) Срезка аналитики за один день
это Гиг инфы. Ну а там дальше умножайте :-)
Ок, загрузили этот гиг. Что дальше происходит с ним?
Чем далее происходит анализ данных?
23.09.2011 22:55, Oleg Matveyev пишет:
10 млн - данные за один день :-) И только за 3 региона, а в планах
поболее. Фармрынок очень быстро меняется :-) Срезка аналитики за один
день это Гиг инфы. Ну а там дальше умножайте :-)
Ок, загрузили этот гиг. Что дальше происходит с ним?
Чем далее
22.09.2011 11:47, Андрей Кручинин пишет:
Убивать саму таблицу и потом ее перезаливать... Спасибо, база падает :-)
Что, и доказательства есть? Если да, то трекер об этом знает?
--
Дмитрий Еманов
22.09.2011 12:21, Dmitry Yemanov пишет:
22.09.2011 11:47, Андрей Кручинин пишет:
Убивать саму таблицу и потом ее перезаливать... Спасибо, база падает :-)
Что, и доказательства есть? Если да, то трекер об этом знает?
Дим, не придирайся :-) Чуть ниже ветка Битая база и тормоза. Мы еще с
Андрей Кручинин ...
Объясню - делается заливка большого объема информации. Если ее просто заливать в таблицу - время 7-10 минут, если делать сначала
удаление данных в таблице а потом заливку свежей информации - то получается затратное время около часа.
Дропнуть (деактивировать) индексы и
22.09.2011 13:44, Vlad Khorsun пишет:
Объясню - делается заливка большого объема информации. Если ее просто
заливать в таблицу - время 7-10 минут, если делать сначала удаление
данных в таблице а потом заливку свежей информации - то получается
затратное время около часа.
Дропнуть
22 сентября 2011 г. 11:47 пользователь Андрей Кручинин an...@bk.ru написал:
А можно во время работы обновить структуру View? И если это сделать - какие
будут последствия?
Объясню - делается заливка большого объема информации. Если ее просто
заливать в таблицу - время 7-10 минут, если делать
22.09.2011 14:24, Roman Simakov пишет:
22 сентября 2011 г. 11:47 пользователь Андрей Кручининan...@bk.ru написал:
А можно во время работы обновить структуру View? И если это сделать - какие
будут последствия?
Объясню - делается заливка большого объема информации. Если ее просто
заливать в
А если во временную таблицу заливать, а потом insert or update?
Дмитрий
Добрый день!
Вроде, http://tracker.firebirdsql.org/browse/CORE-3101 стоит как
исправлено. А у меня на 2.5.1 снова выскакивает
action cancelled by trigger (1) to preserve data integrity.
Cannot update trigger used by a CHECK Constraint.
При попытке SET DEFAULT 0.
Никто не в курсе в чем
доп инфо:
сервер 2.5.1.26356
база мигрирована с яфила.
Привет!
Подскажите можно сделать индекс не полю а например на основании udf, которая
будет обрабатывать блоб?
Можно сделать так что бы не все записи добавлялась в индекс?
Ответ на вопрос зачем: например в таблице очень много записей и нужно
искать только небольшое количество по
Вы не поняли, повторю.
Допустим есть в таблице 1 записей.
Если я строю по ней индекс, то в индекс будут добавлены все записи из
таблицы, т.е. все 1.
Мне нужно поострить индекс в который будут добавлены, например только 7%, от
общего количества записей. Просто остальные записи для
Привет!
Мне нужно поострить индекс в который будут добавлены, например только 7%, от
общего количества записей. Просто остальные записи для поиска по этому
индексу не нужны. Наличие не нужных записей в индексе очень заметно тормозит
вставку новых записей в таблицу.
Ну а вынести эти 7% в
19.09.2011 14:33, Михаил Викторович пишет:
Мне нужно поострить индекс в который будут добавлены, например только 7%, от
общего количества записей. Просто остальные записи для поиска по этому
индексу не нужны. Наличие не нужных записей в индексе очень заметно тормозит
вставку новых записей в
Решение связанное с разбиением таблиц очевидное, и не интересное совсем.
Вопрос про индексы остался открытым или твердое нет?
-Original Message-
From: ru-firebird@googlegroups.com [mailto:ru-firebird@googlegroups.com] On
Behalf Of dennis redozubov
Sent: Monday, September 19, 2011 2:52 PM
Решение связанное с разбиением таблиц очевидное, и не интересное совсем.
есть два варианта:
а) разбить таблицу на две одинаковых, в одной 7%, в другой 93%
б) сделать еще одну таблицу, в которой хранится только одно поле - PK из
большой таблицы.
те самые 7% PK
В вашем случае в таблице лучше
Михаил Викторович ...
Подскажите можно сделать индекс не полю а например на основании udf, которая
будет обрабатывать блоб?
Да.
Можно сделать так что бы не все записи добавлялась в индекс?
Нет.
--
Хорсун Влад
Khorsun Vlad wrote:
Я бы начал с настройки PerfMon'а и сопоставления его логов.
Свип можно отследить, мониторя OIT и OAT.
Кто бы написал тулзу, которая отображает разницу между OIT и OAT в
perfmon :).
Я просто вот думаю: sweep конечно тозмозит всех, но не настолько же.
Есть конечно
Подскажите можно сделать индекс не полю а например на основании udf, которая
будет обрабатывать блоб?
Можно сделать так что бы не все записи добавлялась в индекс?
Ответ на вопрос зачем: например в таблице очень много записей и нужно
искать только небольшое количество по специфичному индексу,
Таки барабашки продолжаются. Опять подлегла.
Unsuccessful execution caused by a system error that precludes
successful execution of subsequent statements.
database file appears corrupt (BaseName).
wrong page type.
page 302478 is of wrong type (expected 7, found 5).
Unsuccessful execution
А это откуда может быть?
gfix -v -full base_name -user UserName -password PAssword
Fatal lock manager error: invalid lock id (133696), errno: 22
--Invalid argument
Такие же сообщения выходят на бекапах.
--
Андрей Кручинин
www.med-zakaz.ru
Для особо извращенных - http://мед-заказ.рф :-)
Есть БД под FB2.0 SS. С ней постоянно работают несколько служебных
программ и периодически пользователи.
В служебных программах происходят только простейшие select/insert,
которые выполняются обычно мгновенно. Там так же сделана сигнализация
(вывод в лог) если какой то запрос будет выполняться
16.09.2011 11:45, Андрей Кручинин пишет:
отрыли в логах такую запись:
[ 2472.739221] fb_inet_server.[16184] general protection ip:7f8fd867c7b8
sp:7fff7d078e58 error:0 in libfbembed.so.2.1.3[7f8fd85c+323000]
Я не спец в нуксах, можно разжевать данную ошибку?
--
Андрей Кручинин
Андрей Кручинин ...
Таки барабашки продолжаются. Опять подлегла.
Unsuccessful execution caused by a system error that precludes successful
execution of subsequent statements.
database file appears corrupt (BaseName).
wrong page type.
page 302478 is of wrong type (expected 7, found 5).
Это
Андрей Кручинин ...
16.09.2011 11:45, Андрей Кручинин пишет:
отрыли в логах такую запись:
[ 2472.739221] fb_inet_server.[16184] general protection ip:7f8fd867c7b8 sp:7fff7d078e58 error:0 in
libfbembed.so.2.1.3[7f8fd85c+323000]
Я не спец в нуксах, можно разжевать данную ошибку?
general
Alexey Popov ...
...
Частота появления таких записей примерно стабильна и составляет 1 раз в 24-25
часов.
Я бы начал с настройки PerfMon'а и сопоставления его логов.
Свип можно отследить, мониторя OIT и OAT.
--
Хорсун Влад
В письме от Fri, 09 Sep 2011 23:07:17 +0400, Андрей Кручинин
an...@bk.ru сообщал:
Ну и пошло то что описывал - коннекты просто тупо подвисали через раз.
На двуядерном проце... На классике...
Может он так и распределяет соединения по round-robin, на первый/второй
процессор ?
Тогда
Второй. А еще быстрее будет delete безо всяких процедур и циклов.
так не все записи же надо удалять. тогда доп вопрос:
несколько десятков delete, каждый с условием IN на тысячу
идентификаторов будут быстрее, чем цикл с одиночными удалениями?
12.09.2011 17:49, A K пишет:
Второй. А еще быстрее будет delete безо всяких процедур и циклов.
так не все записи же надо удалять
Для этого существует WHERE-кляуза.
несколько десятков delete, каждый с условием IN на тысячу
идентификаторов будут быстрее, чем цикл с одиночными удалениями?
есть большая таблица. миллиона записей. все индексы снесены.
стоит задача удалить часть записей. какой вариант отработает
быстрее:
1)
create procedure del
as
declare variable id integer;
begin
for select id from table into :id do
begin
if (chеck some condition)
then delete from
Если бы на все это был воспроизводимый тест кейс, то и другие проверили
бы, и разработчики быстро исправляют, т.к. это был бы явный баг.
А так, просто печальный рассказ что что то не работает.
09.09.2011 18:51, A.Truhin пишет:
Если бы на все это был воспроизводимый тест кейс, то и другие проверили
бы, и разработчики быстро исправляют, т.к. это был бы явный баг.
А так, просто печальный рассказ что что то не работает.
Есть битая база, 50 Гб
--
Андрей Кручинин
Андрей Кручинин ...
Есть битая база, 50 Гб
Так что битое-то ? Есть хоть что-то осязаемое - ошибка в программе,
сообщение в логе, проблемы при валидации ?
--
Хорсун Влад
plasmorf ...
Доброе время суток.
У меня возникли вопросы:
Все ответы есть в релизнотах.
1. Пользователь имеющий права роли RDB$ADMIN почему-то может менять
пароль SYSDBA - это так и задуманно?!!
Да, потому что он и есть SYSDBA, который может менять пароль любого
пользователя.
2.
Столкнулись с такой проблемой:
После того как количество подключенных пользователей превысило 40 резко
упала производительность системы (процессы fb_inet_server находятся в
ожидании Статус D в top и load average скачет от 13% до 20%)
В это же время копирование файлов в пределах RAID идет с
On 5 сен, 13:25, Khorsun Vlad hv...@optima.com.ua wrote:
plasmorf ...
1. RDB$ADMIN -
SYSDBA - ?!!
Нет, любой пользователь (НЕ SYSDBA), имеющий права RDB$ADMIN может
сменить пароль SYSDBA.
, SYSDBA,
.
2. SYSDBA
RDB$ADMIN?
RTFM, GRANTED BY
Это понятно, однако как быть с
plasmorf ...
On 5 сен, 13:25, Khorsun Vlad wrote:
Нет, любой пользователь (НЕ SYSDBA), имеющий права RDB$ADMIN может
сменить пароль SYSDBA.
Релизноты кто читать будет ? Что означает роль RDB$ADMIN, по-твоему ?
RTFM, GRANTED BY
Это понятно, однако как быть с ситуацией, когда один из
Здравствуйте.
Модернизировали сервер меняли Raid контроллер и жесткие диски и в связи с
этим переустановили OpenSuse (было 10.2 32 bit стало 11.3 64bit)
Установлен FB 2.0.6 CS 64 bit, DefaultDbCachePages 512 (пробовали и 256)
Столкнулись с такой проблемой:
После того как количество
Недоговариваешь, однако.
От Вас ничего не утаишь. Для идентичности структуру менял, но по ошибке из
всех архивов два затесались версии 2.0. Менял давно, ошибок ПО не выдавало,
до недавнего момента. В одну процедуру добавлял поле, вот и наткнулся на то,
что две базы не хотят меняться потому что
Вадим, добрый вечер,
Вряд ли это Линукс виноват. Для интереса поставьте старую/другую
версию, конечно,
но сдается мне, что это другая собака проявилась из-под грунта.
Пишите, если что.
С уважением,
Алексей Ковязин
On 30 авг, 11:22, Vadim Mescheryakov vadim.mescherya...@del-fin.ru
wrote:
Dmitry Yemanov ...
26.08.2011 16:08, reshetnyakvkt пишет:
Прошу помощи у гуру, который день ломаю голову над проблемой
перегнать базу
из 2.0 в 2.1.
Недоговариваешь, однако.
А эту ошибку не знаю как решить, что она означает:
gbak:committing metadata
gbak: ERROR:invalid request BLR at
Здравствуйте, уважаемые!
Готовимся переводить базы серверов клиентов с FB 1.5 на FB 2.5. Некоторые даже
круглосуточные.
(Речь идет об автовокзалах)
Однако, т.к. действия по переводу систем будут проводиться по большей части местными сисадминами, то не могу
дать никакой гарантии, что заменят
Ovchinnikov Vasily пишет:
Я достаточно параноидален, чтобы таки продолжать чувствовать какой-то подвох в
связке клиент 1.5 + база 2.5 в
своем случае?..
Да, забыл добавить, что программы общаются с сервером посредством FIBPlus.
Так что напрямую к API никто не лазит.
--
Regards,
Ovchinnikov
База хоть и крутится под 2.5, но пока не задействованы никаких вкусных
новых возможностей из 2.5, по текстам SQL-запросов все строго в режиме
совместимости с 1.5.
...
подвох в связке клиент 1.5 + база 2.5 в своем случае?..
никаких проблем, кроме неиспользованных возможностей
Oleg Matveyev пишет:
База хоть и крутится под 2.5, но пока не задействованы никаких вкусных новых
возможностей из 2.5, по текстам
SQL-запросов все строго в режиме совместимости с 1.5.
...
подвох в связке клиент 1.5 + база 2.5 в своем случае?..
никаких проблем, кроме неиспользованных
Ovchinnikov Vasily ...
Я достаточно параноидален, чтобы таки продолжать чувствовать какой-то подвох в
связке клиент 1.5 + база 2.5 в своем случае?..
Могут быть проблемы с отображением новых видов ошибок. Локальный протокол не
совместим. В остальном проблем быть не должно.
--
Хорсун Влад
Khorsun Vlad пишет:
Ovchinnikov Vasily ...
Я достаточно параноидален, чтобы таки продолжать чувствовать какой-то подвох в
связке клиент 1.5 + база 2.5
в своем случае?..
Могут быть проблемы с отображением новых видов ошибок. Локальный протокол не
совместим. В остальном проблем быть не
26.08.2011 16:08, reshetnyakvkt пишет:
Прошу помощи у гуру, который день ломаю голову над проблемой
перегнать базу
из 2.0 в 2.1.
Недоговариваешь, однако.
А эту ошибку не знаю как решить, что она означает:
gbak:committing metadata
gbak: ERROR:invalid request BLR at offset 513
gbak:
Vlad Khorsun wrote:
Потому что ты ещё и хочешь потоковый анализ показаний делать,
насколько я
понял. Т.е. кто-то должен держать в памяти последние N показаний, и
*быстро*
реагировать на резкие их изменения.
Быстро не значит мгновенно. Есть критерии, логика которых затрагивает
измерения
Кстати, файл antlr-runtime-3.0.1.jar находится в папке client-java\lib.
Khorsun Vlad wrote:
Если тебе нужно отражать показания сотен датчиков *немедленно*, то
никакая
СУБД тебе не подойдёт.
Это ещё почему? Вполне быстро можно выбрать 100 последных записей по
индексу. Минимальный уровень латентности не реалтаймовский, но и 10сек
это много. Все показания
Alexey Popov ...
Khorsun Vlad wrote:
Если тебе нужно отражать показания сотен датчиков *немедленно*, то никакая
СУБД тебе не подойдёт.
Это ещё почему?
Потому что ты ещё и хочешь потоковый анализ показаний делать, насколько я
понял. Т.е. кто-то должен держать в памяти последние N
Привет!
Единственная видимая пока грабля - предел номера транзакции, которая
хотя вылезет через годы, но тоже неприятно.
Если у тебя будет железо (с операционкой), которое вообще будет безостановочно
работать
ГОДЫ, то вопрос выбора БД тебя вообще волновать не будет. Хоть
Терадату бери - её
22 августа 2011 г. 8:42 пользователь Евгений Килин j...@mobil-soft.ruнаписал:
А где ты взял jaybird22_x64.dll?
Там ещё Евгений писал о файлах, и как раз указал на этот файл. Почему-то
теперь его сообщения нет. Может быть он сам удалил его.
Там ещё Евгений писал о файлах, и как раз указал на этот файл. Почему-то
теперь его сообщения нет.
Может быть он сам удалил его.
Спасибо!
Vlad Khorsun wrote:
Не, экономить номера транзакций тут нет никакого желания.
Если ты собрался каждое показание сохранять в отдельной тр-ции, то я
такое не лечу,
это в другое учреждение :)
А зачем оприори делать через жопу? Если датчик допустим даёт показания
раз в 10 сек (или даже
Alexey Popov ...
Vlad Khorsun wrote:
Не, экономить номера транзакций тут нет никакого желания.
Если ты собрался каждое показание сохранять в отдельной тр-ции, то я такое
не лечу,
это в другое учреждение :)
А зачем оприори делать через жопу?
Во-первых *а*приори. Во-вторых - писать
Yurij wrote:
Если не писать напрямую с датчика в базу - все равно нужны будут
какие-то пляски с бубном насчет получить отчет по данным, которые
еще в базу не попали.
Не просто отчёты, а поиск в реальном времени нештатных и особых ситуаций.
Впрочем, я скидываю такие данные в базу одной
Khorsun Vlad wrote:
Во-первых *а*приори. Во-вторых - писать из датчика напрямую в БД
это и есть через жопу. Впрочем я выше написал что такое не лечу :)
Буфер есть, но только для нештатных ситуаций.
Я так и не понял, как ты предлагаешь вставлять записи, идущие от датчика
например раз в 1
Alexey Popov avp@... writes:
Не просто отчёты, а поиск в реальном времени
нештатных и особых ситуаций.
Нет, у меня такое неприемлимо. Показания должны быть
максимально
оперативно быть отображены и проанализированы.
Можно конечно это делать
минуя БД, но это опять усложнение.
Если
Alexey Popov пишет:
Мы уже тут очертили основные проблемы на этом пути. Есть три метода:
1) Свалить все измения в одну таблицу.
2) Партиционировать по разным таблицам
3) Аналогично по разным БД
Я приемлю только первый способ. Но его сервер не осилит.
А если EXTERNAL TABLES привязать?
Писать
Alexey Popov ...
Khorsun Vlad wrote:
Во-первых *а*приори. Во-вторых - писать из датчика напрямую в БД
это и есть через жопу. Впрочем я выше написал что такое не лечу :)
Буфер есть, но только для нештатных ситуаций.
Я так и не понял, как ты предлагаешь вставлять записи, идущие от датчика
Yurij wrote:
Такое чувство что не взлетит на FB.
На весьма хорошем железе взлетит и на FB, имхо.
Вопрос не только в железе. Больше к алгоритмам работы FB которые мало
оптимизированы на такие объёмы. Предел номера транзакции, скорость
prepare, размер TIP и PIP, глубина индексов, не 100%
Alexey Popov ...
Yurij wrote:
Такое чувство что не взлетит на FB.
На весьма хорошем железе взлетит и на FB, имхо.
Вопрос не только в железе. Больше к алгоритмам работы FB которые мало
оптимизированы на такие объёмы.
Ну-ка, ну-ка, хотелось бы подробнее...
Предел номера транзакции,
Vlad Khorsun wrote:
Предел номера транзакции,
Причём тут такие объёмы ???
Предел в 2 миллиарда транзакций непреодолим.
Остальные утверждения были больше вопросами
не 100% заполнение страниц данными,
Это к dbf\csv\txt - там 100%.
Если в базу делается только insert и select, то
Если кому-то нужно решение проблемы, то читайте тут:
http://tech.groups.yahoo.com/group/Firebird-Java/message/10464
В письме от Sat, 20 Aug 2011 02:50:39 +0400, Oleg Matveyev
oleg.matve...@gmail.com сообщал:
вероятно потому, что для x64 тебе надо использовать 64битную
FBEmbedded.dll
Это должно зависеть от битности Eclipse и JVM - а про них и не сказано
какие они
--
Написано в почтовом клиенте
Alexey Popov ...
Vlad Khorsun wrote:
Предел номера транзакции,
Причём тут такие объёмы ???
Предел в 2 миллиарда транзакций непреодолим.
Ну так не надо в него стучаться лбом - это больно и не нужно :)
В 3-ке сделаем 4млрд. Потом посмотрим на возможность дальнейшего
расширения этого
denixx baykin ...
Ааа. Зря я там спросил, наверное :)
Берёшь свои слова назад ? :)
Ведь на манеже всё те же. :)
Это ты о чём ? Ты здесь часто встречал Романа (Roman Rokytskyy) или Mark
Rotteveel ?
--
Хорсун Влад
IMHO
мне сразу показалась сама идея странной: JB+ Emb.
ведь Emb подразумевает распостраняемое приложение, которое можно легко
запустить - без установки.
но:
1. неизвестно, есть ли вообще той машине, где будем запускаться - Java.
2. если она есть - то какая она - 64/32бита
p.s. тоже относится
В почте текст вижу, в веб-интерфейсе не вижу.
Берёшь свои слова назад ? :)
Слова назад беру. :)
Это ты о чём ? Ты здесь часто встречал Романа (Roman Rokytskyy) или Mark
Rotteveel ?
Романа я тут вроде видел, он даже отвечал на какой-то вопрос.
Посмотрел - это было в 2006-2008 годах )
Так
21 августа 2011 г. 14:48 пользователь Oleg Matveyev o_matv...@mail.ruнаписал:
но:
1. неизвестно, есть ли вообще той машине, где будем запускаться - Java.
2. если она есть - то какая она - 64/32бита
Приложение для узкого круга пользователей, там уж разберемся, какая ява на
компе стоит ) Ну и,
Vlad Khorsun wrote:
Предел в 2 миллиарда транзакций непреодолим.
Ну так не надо в него стучаться лбом - это больно и не нужно :)
Не, экономить номера транзакций тут нет никакого желания.
В 3-ке сделаем 4млрд. Потом посмотрим на возможность дальнейшего
расширения этого лимита.
Это уже
Alexey Popov avp@... writes:
И откуда возьмётся случайное перемешивание, если
данные приходят с
датчиков
весьма последовательно - т.е. кластеризация по
времени и так
присутствует натуральным
образом ?
Я про то, что это никто не гарантирует явно. Например b/r
теоретически
может всё
Это уже новая ОДС.
донкихотанама
Yurij wrote:
Там есть печаль с такими данными, связанная с
равномерным приходом данных по времени и индексам.
Если выбирать данные по одному датчику по индексу,
то оно читает примерно так одна запись из таблицы -
одно чтение страницы данных. Потому что на этой странице
все остальные записи -
В письме от Sun, 21 Aug 2011 15:48:10 +0400, Oleg Matveyev
o_matv...@mail.ru сообщал:
1. неизвестно, есть ли вообще той машине, где будем запускаться - Java.
Так можно её с собой таскать просто, в подпапке.
Как делают IBM Lotus Notes, IBM Symphony (примеры Eclipse RCP)
--
Написано в
Посоветуйте пожалуйста среду разработки для Firebird 2.5
Переделываю хранимые процедуры из БД MySQL в БД Firebird.
Процедуру пытаюсь создавать при помощи IBExpert.
Это вменяемая среда?
FlameRobin вроде уже устарел на несколько лет.
Читал здесь про среды разработки:
Здравствуйте, denixx.
Вы писали 21 августа 2011 г., 23:56:08:
Посоветуйте пожалуйста среду разработки для Firebird 2.5
Переделываю хранимые процедуры из БД MySQL в БД Firebird.
Процедуру пытаюсь создавать при помощи IBExpert.
Это вменяемая среда?
Это одна из самых вменяемых. Для
21 августа 2011 г. 20:11 пользователь Владимир Аксенов
fr...@academ.orgнаписал:
Это одна из самых вменяемых.
Ну раз так, то напрашивается ещё одна тема :)
Alexey Popov ...
Vlad Khorsun wrote:
Предел в 2 миллиарда транзакций непреодолим.
Ну так не надо в него стучаться лбом - это больно и не нужно :)
Не, экономить номера транзакций тут нет никакого желания.
Если ты собрался каждое показание сохранять в отдельной тр-ции, то я такое
не
FlameRobin вроде уже устарел на несколько лет.
Вру, в апреле 2011 вышла свежая версия.
Но я не пробовал её.
21 августа 2011 г. 20:21 пользователь Vlad Khorsun hv...@optima.com.uaнаписал:
Такова селява.
Хорошее выражение, надо бы запомнить :)
Результаты 201 - 300 из 33066 matches
Mail list logo
