SangYong,

1) По умолчанию CURBID broker рассоединяет коннекшин сессии через 300 секунд. Ее можно изменить по желанию. Подродности в мануале http://bit.ly/h5Q06V.

2) На счет зарезервированной ошибки, можно поподробнее (скрин, среды, версии, пути репликации), а то я мысли не умею читать.

3) CUBRID отличается скоростью чтения, есть много внутренних оптимизаций. Что касается скорости добавления, то есть одно особенность, на которую разработчики не обращают внимания. Если в таблице использованы какие-либо индексы, будь то первичный ключ, уникальное поле или сам индекс, то при каждом добавлении новой строки, происходит индексация. Это стабильно в любой СУБД. Все зависит каким образом добавляются данные. Если через импортирование, то можно колосально ускорить добавление с помощью prepared SQL. Это подробно объяснено на официальном форуме http://bit.ly/hMM04N. Как-нибудь обязательно сделаю то же самое здесь на русском.

4) Что касается зеркалирования, то CUBRID HA (High-Availability) будет в помощь. Она настолько мощная, что выполнит любую задачу зеркалирования, репликации и высокой доступности. Тут есть ее описание http://bit.ly/eocZr1, а здесь сам туториал на английском http://bit.ly/gYKeO9.

Если будут другие вопросы, буду рад ответить.

SangYongа вот если на тачке два сетевых интерфейса
как заставить сервер открыть порты на обеих сетевухах

В CUBRID'е можешь добавить несколько дополнительных брокеров, каждый из которых может связывать клиентскую программу с сервером через отдельно указанный в брокере порт. Посмотри на первую архитектуру, указанную в http://bit.ly/dDYqeM.

SangYong,

Можешь поподробнее объяснить что-за ошибка? Интересно стало. Может я как-то смогу помочь.

Что ты хочешь сделать? Просто подсоединиться, а потом что? Выдирать данные или, наоборот, записывать? Какая ошибка? Можешь ее сюда запостить?

SangYong,

Не могу найти дистрибутив MS Acess 97. Поищу вечерком и потыркаю, как ты говоришь. Завтра выйду и скажу результат и за одно постараюсь ответить на все предыдущие вопросы.

P.S. че бы тебе уже на новую не пересесть, а? Уже давно не 97-й год. И приятней будет работать самому.

SangYong,

Здарова! Никак не было времени выйти в нет. Есть вопрос. Какая у тебя архитектура твоей машины? Случайно не 64-битная?

SangYong,

У Майкрасофта есть одна известная проблема, которая влияет на работу с ODBC драйверами. Посмотри сюда http://support.microsoft.com/kb/942976/en-us/. Здесь говорится, что если хочешь создать пользовательский DSN для 32-битного драйвера Microsoft Access Driver, которая не имеет 64-битного драйвера, и пытаешься вызвать функцию SQLDataSources в 64-битной программе, то у тебя будет выдавать ошибку "Data source name not found and no default driver specified".

В твоем случае тебе надо установить CUBRID такой же архитектуры, что и твой Access. Поэтому важно узнать, какая архитектура твоей системы и какой архитектуры ты используешь CUBRID.

SangYong,

Мне просто смешно стало сейчас. Аж.... Все эти переписки...., а уточнить забыл: ты саму базу хоть запустил?

Вот что я сделал:

В CUBRID'е:

1) Создал базу demodb и таблицы, которые мне надо.

***) И тут самое главное!!!*** Запустил базу в командной строке: cubrid server start demodb . Если не запустишь базу, ты не сможешь подключиться к нему через Access.

В MS Access:

1) Создал новую базу (еще даже не сохранил и не назвал).
2) Внешние Данные (External Data) -> ODBC Database.
3) В появившемся окне выбрал "Связать с источником данных, создав связную таблицу" (Link to the data source by creating a linked data). Жмешь ОК.
4) Затем выбрал "Machine Data Source" -> CUBRID. Если CUBRID'а еще не видешь, значит ты еще не создал DSN (Data Source Name) для него. Тогда посмотри тут туториал http://www.cubrid.org/setup_cubrid_odbc_driver.

И все готово. Попробуй. Затем запости результаты. Жду с нетерпением.

SangYongда - я не только запускал дему
я сделал свою базу, подключился
к ней через ODBC из MSACCESS2007
залил в нее около 300 000 записей
потыркал на скрость фильтрации и
сортировки непроиндексированных
данных - оч.вс хорошо...но в более
сложные штуки не лазил...тригеров,
трансакций...я просто попытался
подкатить на MSACCESS97 и получил
облом. Что я могу сделать: могу скинуть
портабл office97 - установки не нужно
можете сами поробовать - может
какие настройки драйвера ODBC нада
выставить)

Ответил на Ваши вопросы в блоге http://www.sql.ru/blogs/cubrid/984#add-comment.

1) Кюбрид, как Вы уже заметили, очень хорошо работает с неиндексированными данными. Фильтрация через Access должна проходить незаметно.
2) Простота установки - думаю, Вы уже убедились. Вот горячий бэкап - то, чем отличается CUBRID от MySQL. CUBRID дает возможность делать и горячий бэкап, и синхронную репликацию, чего нет в MySQL. Чтобы использовать такие фишки в MySQL, надо покупать коммерческую лицензию или лицензию третий разработчиков.
3) Что касается загрузки данных из текстовых файлов, то в CUBRID можно, конечно, импортировать данные из CSV. Можно также отключить логгинг в брокере, что значительр ускорит скорость ввода данных.
4) В CUBRID можно создавать Java Stored Procedures. Что касается тех MSSQL функций, пожалуйста, приведите пример.
5) Блокировнки на чтение в CUBRID тоже есть, их даже можно самому контролировать.

iv_an_ruCUBRID RDBMS,

Можно неприличный вопрос? Не могу нагугулить результаты прогонов TPC-W для CUBRID. TPC-C, кстати, тоже. Не подскажете, где посмотреть?

Мы не проводили тестов на основе TCP-W и TCP-C. Но Вы можете узнать более подробно о других сравнительных тестах, которые мы проводили, на оф. сайте http://cubrid.org/performance_results.

iv_an_ru,

iv_an_ruэто ж-ж неспроста

Соглашусь. Но не в этом случае. Есть тому одна причина. На данный момент для нас это не приоритет . Вот и все.

Если пользователю есть возможность провести этот тест, мы будем больше, чем рады, и даже поможем. Но сейчас мы работает над совместимостью с MySQL, над улучшением томов для еще меньшего размера данных и индексов, над драйверами, над допольнительными подсказками для еще лучшей индесации (на данный момент индексация у CUBRID намного умнее, чем у MySQL и MS SQL). Дел очень много. Поэтому по возможности мы разспределяем человеческие ресурсы на более важные задания.

Что касается уже существующих тестов, так они по заказу пользователей. Обычно они дают свои данные (большие данные с реальных сервисов), дают свои запросы (особенно те, которые чаще всего вызываются), и дают информацию о своей нынешней СУБД. Затем их ДБ администраторы приходят к нам, и мы вместе создаем сценарий теста, проводим тест, и смотрим, где лучше, где хуже. Анализ вместе с рекомендациями затем даем пользователю. Потом тот решает, что делать, переходить на CUBRID или нет. Затем по разрешению пользователя мы публикуем результаты.

Поэтому здесь немного другая история.

Насчет тестдрайвера, как Вы называете, несколько пользователей уже работают над небольшим проектом на PHP, который позволит свободно тестировать и сравнивать по производительности MySQL, MS SQL, и CUBRID между собой. Проект открытый и разрабатывается в SF.net https://sourceforge.net/projects/cubridperf/files/ .

Если кому интересно, можете скачивать проект, ставить на локалке и тестить все базы. Затем можете либо публиковать у себя в блоге или рассказать о результатах на форуме. Также Вы можете закоммитить в репозиторий свои изменения или дополнительные тесты.

Если будут идеи, буду рад их выслушать и обсудить. В принципе, в CUBRID мы открыты всем и всему. Так что, пожалуйста, связывайтесь с нами, и давайте дружить :).

iv_an_ru,
iv_an_ruэто ж-ж неспроста
Соглашусь. Но не в этом случае. Есть тому одна причина. На данный момент для нас это не приоритет . Вот и все.

Если у пользователя есть возможность провести этот тест, мы будем больше, чем рады, и даже поможем. Но сейчас мы работает над совместимостью с MySQL, над улучшением томов для еще меньшего размера, над драйверами, над допольнительными подсказками для еще лучшей индесации (на данный момент индексация у CUBRID намного умнее, чем у MySQL и MS SQL). Дел очень много. Поэтому по возможности мы распределяем человеческие ресурсы на более важные задания.

Что касается уже существующий тестов, так они по заказу пользователей. Обычно они дают свои данные (большие данные с реальных сервисов), дают свои запросы (особенно те, которые чаще всего вызываются), и дают информацию о своей нынешней СУБД. Затем их ДБ администраторы приходят к нам, и мы вместе создаем сценарий теста, проводим тест, и смотрим, где лучше, где хуже. Анализ вместе с рекомендациями затем даем пользователю. Потом тот решает, что делать, переходить на CUBRID или нет. Затем по разрешению пользователя мы публикуем результаты.

Поэтому здесь немного другая история.

Насчет тестдрайвера, как Вы называете, несколько пользователей уже работают над небольшим проектом на PHP, который позволит свободно тестировать и сравнивать по производительности MySQL, MS SQL, и CUBRID между собой. Проект открытый и разрабатывается в SF.net https://sourceforge.net/projects/cubridperf/files/ .

Если кому интересно, можете скачивать проект, ставить на локалке и тестить все базы. Затем можете либо публиковать у себя в блоге или рассказать о результатах на форуме. Также Вы можете закоммитить в репозиторий свои изменения или дополнительные тесты.

Если будут идеи, буду рад их выслушать и обсудить. В принципе, в CUBRID мы открыты всем и всему. Так что, пожалуйста, связывайтесь с нами, и давайте дружить :).