Объявление от 30.03.2010.
Выяснилось, слишком поздно, что "CodeBase 6.5" не обеспечивает требования ACID в части Isolation (изоляции). Т.е., например, если в одной сессии 1С проводится документ, то в другой сессии могут быть прочитаны измененные и не изменённые строки документа и движения до полного завершении или отката транзакции в первой сессии. Этого не происходит, если обе сессии выполняют и запись и чтение данных в транзакции, т.к. средствами 1С обеспечивается последовательное выполнение транзакций. Но сессии, в которых, например, формируется отчет, будут получать противоречивые данные.
Кроме того, принятый в "CodeBase 6.5", алгоритм выполнения транзакций не обеспечивает должного уровня надежности в режиме "stand-alone" (в моей разработке названо - ПДБД).
Выводы:
1) Данный "проект" - закрыт.
2) Публикация не удаляется ради данного объявления.
3) Дистрибутивы не удаляются, чтобы дать возможность пользователям использовать последнюю версию разработки для успешного переноса своих баз данных на другие СУБД.
4) Я не стал связываться с разработчиками "CodeBase 6.5" по данной проблеме. Т.к., думаю, они не считают это проблемой, если изначально заложили в своей системе такие алгоритмы работы с транзакциями.
Определение термина Isolation из http://ru.wikipedia.org/wiki/ACID
"Во время выполнения транзакции другие процессы не должны видеть данные в промежуточном состоянии. Например, если транзакция изменяет сразу несколько полей в базе данных, то другой запрос, выполненный во время выполнения транзакции, не должен вернуть одни из этих полей с новыми значениями, а другие с исходными."
В этой цитате, для нашего случая, нужно читать слово "поле" как слово - "запись".
Объявление от 12.09.2007.
Обнаружена ошибка в CodeBase.
В режиме ПДБД при монопольном запуске сессии 1С активизируются, по умолчанию, режим оптимизации операций ввода/вывода. Если при таких условиях выполняется задача по дополнению записей в таблицы с применением транзакций и после ряда успешно выполненных транзакций выполняется откат очередной транзакции, то это приводит к порче DBF файла. Ошибка “плавающая”, т.е. зависит от размера памяти отведённой под оптимизацию операций ввода/вывода, размера и количества успешно выполненных транзакций и т.д. Я предоставил информацию об этой ошибке в Sequiter Inc. Получен ответ: “We have reproduced this problem. We will continue to investigate and let you know what the solution is.”. До окончательного решения проблемы рекомендую установить единицу в строке № 14 файла DBEng32.ini. В режиме клиент/сервер эта ошибка не наблюдается.
Объявление от 28.11.2007.
Ошибка в CodeBase исправлена в версии 5.1.2.8.