Здравствуйте.
>1. подозрение что там транзакции такая же профонация что и в фоспро, при сбое просто физически >нечему отвернуть неудачную транзакцию.
Схема отката транзакций зависит от инструмента. Либо ОС, либо драйвер.

>2. как делать бэкап ?? (выдергивать шнур чтоб всех из бд выгнать ?)
Нет проблем организовать горячий бэкап. Но обычно в этом нет потребности.

>3. востановится можно только на момент бэкапа, что за бизнес может себе позволить потерять пол дня >работы ?
Протоколирование изменений с возможностью восстановления на момент сбоя реализуется и на
ФС системах без проблем. Можно восстанавливать не только всю базу целиком, но и отдельные
проблемные таблицы.

>При акцессе на терминале - мы имеем N приложений, читающих/пишущих в
>один файл. И, по большому счету, эти приложения ничего друг о друге не
>знают, откуда - никто ничего друг с другом не синхронизирует.
Про акцесс не знаю, но ФС системы работают обычно через один вход, либо несколько приложений,
использующих общие dll, в одной из которых содержится логика модификации БД.

>Для ФС на каждого клиента запускается своя копия программы.
Если приложение мульти-dll и работает под терминалом, то на каждого клиента запускается
отдельная копия exe. dll-ки грузятся один раз. Например, если все приложение 20МБ, exe
обычно занимает порядка 200 кб. Общий расход памяти будет ~20МБ (dll)+200кб * количество
пользователей.

Типовой современный компьютер с гигом ОЗУ вполне тянет 20 конкурентных пользователей в терминале.
С хорошим встроенным форматом приложения работают достаточно быстро и надежно.
Про большее количество пользователей на более мощных машинах (которые сейчас не экзотика)сам
не скажу, судя по информации в интернете, тянет до 50 пользователей. При желании можно поднять
более 1 сервера и распределить нагрузку. Мощность компьютеров продолжает расти...
В принципе, по техническим характеристикам связка ФС+терминал сейчас покрыват потребности
малого и среднего бизнеса. В большинстве задач использование или неиспользование SQL-сервера
зависит от личных пристрастий разработчика и имеющихся у него опыта и наработок.
Декстопные форматы обычно рассматриваются с позиции встроенного формата хранения данных,
используемого в составе инструмента разработки "все в одном флаконе". Это дает свои
преимущества как на этапе разработки и тестирования, так и на этапе техподдержки.
Не так давно проводился опрос среди зарубежных разработчиков на clarion по поводу SQL (в
clarion можно эффективно работать как со встроенными форматами, так и с различными SQL-серверами
через ODBC API или нативные акселераторы). Большинство высказалось за продолжение
развития инструментария по встроенные форматы.

>>Протоколирование изменений с возможностью восстановления на момент сбоя реализуется и на
>>ФС системах без проблем. Можно восстанавливать не только всю базу целиком, но и отдельные
>>проблемные таблицы.

>Ни горячий бэкап, ни откат, ни накат транзакций вы нормально не сделаете, если одна сессия ничего >не знает о другой.

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

>>Про акцесс не знаю, но ФС системы работают обычно через один вход, либо несколько приложений,
>>использующих общие dll, в одной из которых содержится логика модификации БД.
>ну и что, что одна DDL ? У них (приложений) есть общие области для согласования действий ?

Запись в базу данных осуществляет один и тот-же код, который опять же генериться автоматически
на основании описания структуры базы данных. Этот код составляет слой процедур, в который
включается контроль целостности, установка дефолтных значений, ведение лога, подсчет оперативных
остатков, если нужно (аналогично генерится код блока проверки содержимого базы данных).
Все остальное работает через этот слой.
Запись в базу данных разруливается на уровне операционной системы. Прежде всего, речь о
транзакциях. Тут могут быть разные варианты. В моем случае нужные таблицы блокируются на
запись, все изменения накапливаются в оперативной памяти, затем пачкой заливаются в черновые
страницы, затем происходит замена адресов страниц. Критичный к сбоям период оставляет небольшие
доли секунды на этапе замены адресов страниц. Транзакции отрабатывают очень быстро. Я, конечно, понимаю, что SQL-сервер более эффективно распараллелит большое число транзакций, но тут речь нужно вести о количестве конкурентных пользователей, начиная с которого это реально нужно.

>>Если приложение мульти-dll и работает под терминалом, то на каждого клиента запускается
>>отдельная копия exe. dll-ки грузятся один раз. Например, если все приложение 20МБ, exe
>>обычно занимает порядка 200 кб. Общий расход памяти будет ~20МБ (dll)+200кб * количество
>>пользователей.[/quote]

>То есть кэшированием данных вы принципиально не пользуетесь ? Ну тогда быстродействие того... >загнется одномоментно. А если каждое приложение отхватит себе для кэша ну хотя бы скромных 50-100 >мег, то как быстро кончится память на вашем супер-пупер компьютере ?

Кэширование обеспечивается на уровне операционной системы и на уровне приложения. В виндовом
сервере, кстати, кэш работает достаточно эффективно. На уровне приложения в составе описанного
слоя работы с базой данных создается ряд процедур, который кэширует данные, но, конечно, для
конкретного пользователя. Последним можно пользоваться, можно нет.
50-100 мег - это цифра не маленькая. Реально каждый пользователь откусывает меньше. Конкретная
величина зависит от задачи. В просмотре данных используется постраничная загрузка информации,
расходы на которую минимальны. Тяжелый отчет в торговом приложении по всем ассортименту может
достигать нескольких мб, но, как правило, более одного такого отчета пользователь делает редко,
далее вызывает из него расшифровки. Да и сам отчет по полному ассортименту делается не так
часто - используются ограничители выборки.
Если бызы большие, то при плохо спроектированном приложении имеется вероятность переполнения
кэша винды. Ну тут, как говорится, делайте все правильно. Проще всего хранить сводные итоги в
закрытых периодах. Далее дело приложения - определить их наличие и использовать, не лопатя
всю базу данных.

>>Типовой современный компьютер с гигом ОЗУ вполне тянет 20 конкурентных пользователей в
>>терминале.
>Такой же сервер потянет сотни и тысячи конкурентных пользователей.

Не знаю, не пробовал.
В крупных системах нужно использовать SQL-сервера, они для этого и созданы. Не будет эффективно
работать одно и то-же приложение на предприятиях с 20-30 пользователями и 100 пользователями.
То же самое и наоборот. Разная идеология организации бизнес-процессов. Вообще же, делать системы
нужно на том, на чем лично Вам выгоднее, не оглядывясь на рекламу каких-либо продуктов, за каждым
из которых стоят чьи-либо экономические интересы.

Не автор...
>А почему в мелких системах SQL сервер не нужно использовать? Инстумент нужно выбирать с запасом >прочности
>
>20-30 и 100 пользователей - один порядок. Правда если из ФС системы выжали всё на что она способна >и 30 пользоватей оня тянет, то сотне на она загнётся, согласен.

Я придерживаюсь мнения, что в системах, ориентированных на малый и средний бизнес,
использование втроенных форматов в связке с терминалом более целесообразно.
Дело, конечно, не в чисто технических характристиках. Просто в системах "все в одном
флаконе" гораздо проще организовать автоматизированный процесс сборки и тестирования
приложений. Затраты на поддержку автономных приложений в условиях, когда у заказчика
нет в штате ИТ-специалистов, также существенно ниже. Время, которое придется тратить
на изучение косяков чужого продукта и всяких нестыковок, возникающих в процессе
межпрограммного взаимодействия, можно более продуктивно потратить на развитие
своего инструментария и углубленное изучение бизнес-процессов заказчика. То есть
мне так выгоднее.
Про количество пользователей, более 20, воздержусь комментировать. Скажу лишь, что
у меня есть коллеги, которые в реальных проектах имеют гораздо больше пользователей.

Есть еще такая система - битрив. Я ее не использую по идеологическим соображениям.
В основном, потому что нужно дополнительно лицензировать каждое рабочее место, а у
меня весь поставляемый софт с лицензией. Битрив - это правильный ISAM-клиент сервер,
перход на него практически не требут модификации приложения, работающего со встроенным
форматом. Судя по доке, в нем есть и кэширование, и пакетное чтение записей, и пересылка
по сети отдельных полей записи, сверху приделан SQL-сервер. Если потребуется более
100 пользователей, можно подключить его. Но это уже из области предположений.

>потрясающе, а идиота которому баба не дала, методично забивающего нулями файл бд тестовым >редактором вы тоже видете ? а проворовавшегося лоха, котрый мимо вашего "функионала" подправляет >цифирки видете ?

Я бы предложил сохранять корректность в высказываниях, если хотите, чтобы я Вам отвечал.
В терминальном сервере пользователь не имеет доступа к физическим таблицам, как и в
случае SQL-сервера. Не имеет доступа к удаленному рабочему столу. При подключении
сразу попадает в прикладное приложение. Некоторые клиенты успешно используют терминальные
станции вместо ПК на рабочих местах - компактно (небольшая подставка под монитор), не
шумит, практически не греется, не требует установки софта вообще. То есть с точки
зрения безопасности все в порядке.

>>Запись в базу данных разруливается на уровне операционной системы. Прежде всего, речь о
>>транзакциях. Тут могут быть разные варианты. В моем случае нужные таблицы блокируются на
>>запись, все изменения накапливаются в оперативной памяти, затем пачкой заливаются в черновые
>>страницы, затем происходит замена адресов страниц. Критичный к сбоям период оставляет небольшие
>>доли секунды на этапе замены адресов страниц. Транзакции отрабатывают очень быстро. Я, конечно, >>понимаю, что SQL-сервер более эффективно распараллелит большое число транзакций, но тут речь >>нужно вести о количестве конкурентных пользователей, начиная с которого это реально нужно.

>свежо придание, но верится с трудом. кто/что чистит " черновые страницы" оставшие от неудачных >транзакций ?

Зачем? Черновые страницы в случае обвала транзакции будут использоваться в следующей
транзакции.

>потрясающе, а идиота которому баба не дала, методично забивающего нулями файл бд тестовым >редактором вы тоже видете ? а проворовавшегося лоха, котрый мимо вашего "функионала" подправляет >цифирки видете ?

Я бы предложил сохранять корректность в высказываниях, если хотите, чтобы я Вам отвечал.
В терминальном сервере пользователь не имеет доступа к физическим таблицам, как и в
случае SQL-сервера. Не имеет доступа к удаленному рабочему столу. При подключении
сразу попадает в прикладное приложение. Некоторые клиенты успешно используют терминальные
станции вместо ПК на рабочих местах - компактно (небольшая подставка под монитор), не
шумит, практически не греется, не требует установки софта вообще. То есть с точки
зрения безопасности все в порядке.

>>Запись в базу данных разруливается на уровне операционной системы. Прежде всего, речь о
>>транзакциях. Тут могут быть разные варианты. В моем случае нужные таблицы блокируются на
>>запись, все изменения накапливаются в оперативной памяти, затем пачкой заливаются в черновые
>>страницы, затем происходит замена адресов страниц. Критичный к сбоям период оставляет небольшие
>>доли секунды на этапе замены адресов страниц. Транзакции отрабатывают очень быстро. Я, конечно, >>понимаю, что SQL-сервер более эффективно распараллелит большое число транзакций, но тут речь >>нужно вести о количестве конкурентных пользователей, начиная с которого это реально нужно.

>свежо придание, но верится с трудом. кто/что чистит " черновые страницы" оставшие от неудачных >транзакций ?

Зачем? Черновые страницы в случае обвала транзакции будут использоваться в следующей
транзакции.

>Проблема в том, что при перерастании порога пользователей, систему приходится выбрасывать и >начинать с нуля. За это местных CIO по головке не гладят.
>Но если организация не растет, и расти не собирается, то можно и на Фоксе писать, и на Аксессе, у >них небось и CIO никакого нет :-)

Какой CIO, если нет штата ИТ-специалистов?
Организации в большинстве случаев развиваются, но перещагнуть из категории небольших в
категорию средних и, тем более, в категорию крупных, не так просто. Если такое
происходит, то обязательно будет сопровождаться кардинальным пересмотром бизнес-
процессов. В этом случае, разумеется, может потребоваться существенная модификация
приложения не зависимо от того, как оно сделано Однако, уверяю Вас, проблем, связанных с ростом, гораздо больше, чем необходимость переделки софта. Я наблюдаю сейчас пару клиентов, которые превратились из компаний с 3-4 компьютерами и штатом в 20-30 работников в компании с 15 компьютерами и штатом порядка сотни работников. Приток новых сотрудников, распределение обязанностей, согласование порядка работы и взаимодействия, банальное использование единой терминалогии... Главное, чтобы система работала максимально эффективно на данном конкретном этапе разития бизнеса.
Да и разбег настолько большой, что мне сложно придумать ситуацию, когда у кого-то из существующих заказчиков возникнет реальная необходимость в использовании SQL-серверов. Много ли Вы видели
компаний, выросших от 10 рабочих мест до 100? И будут ли такие выросшие компании работать с
небольшим софтверным партнером - вопрос больше политический, там другие правила игры.

>Рекомендую посмотреть стоимость лицензиии на терминал-сервер и на стоимость паков
>лицензии для пользователей(устройств)
>Далее сравнить стоимость со стоимостью десктопового решения для SQL сервера и учесть что в
>затаратах на развитие при использовании файл-сервера необходимо предусмотреть полное переписывание >задачи. Насчет того, что затраты на поддержку существенно ниже -Вы погорячились...

Терминальный сервер встроен в Win2000 и Win2003 серверные оси. Дополнительно лицен-
зируется каждое рабочее место. Если не ошибаюсь, порядка 100 у.е.
Если у Вас Win2000 (до 20 пользователей этого чаще достаточно), то есть встроенные
лицензии для Win2000 и WinXP станций. В этом случае дополнительно оплачивать лицензии
на рабочее место не нужно. в Win2003 это прикрыли...
Наиболее эффективно использование терминального сервера в связке с терминальными
станциями. Цены на них несколько зашкалены, т.к. считается, что основное достоинство -
это низкая стоимость владения. Примерно считайте, что стоимость полностью укомплектованной
терминальной станции со всеми лицензиями будет равна стоимости железа обычного ПК.
Для более крупных контор серьезный выигрыш может получиться от использования старой
техники в качестве станций.
Речь идет о MS-терминалах. Если Вы поищете в интернете, то найдете ряд альтернативных
проектов, появившихя за последние 2-3 года. Но это сейчас пока экзотика.

>да и как вы это представляете под виндой ? кто сказал что на терминальном сервере нельзя запускать >другие приложения ?

Это зависит от настройки прав пользователя на терминальном сервере. Если указать
приложение, выполняемое при подключении, то все остальное от него будет закрыто.

>кому нужно рабочее место без мс офиса, с помощью которого с access/dbf файлами можно делать все >что душе угодно.

Думаю, что это стереотип. Но, действительно, некоторые пользователи привыкли к наличию
такой прилады. Я использую только как дополнительную возможность. Т.е. основная
работа не требует наличия постороннего софта, но пользователь может сохранить отчет в
Excel/Calc и дальше с ним работать. Для каждого пользователя можно назначить каталог
по-умолчанию. Если на рабочем месте обычный ПК, то каталог обычно располагается на нем. В
этом случае отчет пользователь сохраняет отчет, переключается на локальный компьютер и работает
с отчетом дальше. Со станций обычно работают те, кому в Офисе делать нечего. Но если потребуется, тоже, думаю, вопрос решаемый. Еще раз заострю внимание, что использование Офиса - это дополни-
тельны сервис. Есть серьезное неудобство - проблематично организовать навигацию по информации
(сводный отчет - более детальный отчет - график - первичнй документ и т.п.)
Кстати, я с access и dbf файлами не работаю. У меня базы шифрованные, 512-битный ключ...

>тогда должен быть заголовок в котором указаны где черновые страницы, пока похоже на буйную >фантазию, можно урл на msdn ?

Ну так я вроде написал, что после заливки информации в черновые страницы выполняется замена
адесов страниц и что это этап, на котором может произойти сбой. Однако он настолько маленький,
что при работе на локальном компьютере (или под терминалом)вероятность близка к нулю. Замечу еще,
что перед заменой адресов создается специальный лог, в котором фиксируются таблицы и адреса
замещаемых страниц. Если все же произойдет сбой, то драйвер должен откатить изменения. Хотя
тут может быть не все так гладко. В целом, как показывает опыт, уронить базу на терминальном
сервере можно только вырубив питание в момент замещения страниц. Но при таком раскладе думаю,
что последствия для SQL-сервера будут еще плачевнее.
Насчет msdn я что-то не понял. Вам, наверно, нужно что-нибудь про организацию b-деревьев
почитать. Например, старенькую книжку Ульмана "Базы данных на Паскале" или что-то подобное.

Здравствуйте, Сергей!
>Снова никто не упомянул современные технологии, позволяющие сетереть различия между ФС и КС , >например, Web Services...

Но тогда, как я понимаю, будет Web-интрфейс, что не всегда допустимо.
В принципе, сейчас для распространенных форматов ( т.ч. и для dbf, насколько знаю),
есть IP-сервера. Схема примерно такая. На "сервере" (ос не ниже Win2k, не обязательно
серверная) запускается сервис. В этом сервисе регистрируем dll, в которой собраны
декларации базы данных. Эта dll генерится автоматически при сборке проекта. В основ-
ных модулях проекта автоматчески выполняется подмена драйвера, после чего мы уже не
напрямую модифицируем файло по сети, а шлем запросы на серверную dll, которая и
выполняет реальную модификацию данных. Сам серверный компьютер на прямую по сетке может
быть не доступен. Структурно это несколько напоминает работу битрива. При этом доступна
фильтрация нформации на сервере, чтение блока записей за одно обращение и возможность создания серверных переменных и процедур. Серверные процедуры пишутся на том-же языке, что и основной проект, и располагаются в dll на сервере.
Стоимость такого решения в моем случае составляет 8-12 тыс.руб., если покупать у
российского дистрибьютора, и зависит от периодически проводимых ценовых акций.
Для твоих пользователей дальнейшее распространение бесплатно.
Один зарубежный коллега писал,что без проблем работает 50 пользователей, часть через
интернет. Добавлю еще, что опсаный подход может быть использован и в саязк с SQL-сер-
верами, поскольку создает защищенный канал.
Однако, поскольку я тяготею к монолитным приложениям, то в реальных проектах не
пользую.

>А почему сразу не взять SQL сервер?

Все правильно. IP-сервера по скорострельности и функциональности не будут конкурировать.
Сделано для снятия проблем с надежностью в ФС-приложениях, а также для обеспечения
доступа к ним через интернет. При этом переписывать приложения почти не надо.
Но нарушается монолитность приложения - часть кода на сервере, часть на клиенте.
Поэтому я тоже думаю, что проще использовать SQL-сервер. А если стремиться сохранить
монолитность приложения - то терминал.

>лана, щаз все же загляну в описание mdb, разберемся в вашей фантазии.

Думаю, что стоит побольше знать об альтернативных технологиях, даже
если не собираешься их использовать. Тогда меньше наивных мыслей и больше
плодотворных идей... Успехов.

Выкладываю выдержку из доки и выдержку из переписки разработчиков по поводу транзакций в топспидовских таблицах. На этом завершаю обсуждение.

=======================================================
Transaction Processing--the TCF File
Speedy Logging and Automatic Recovery

TopSpeed transaction logging is very fast (about 100 times faster than the Clarion
driver). With LOGOUT, the TopSpeed engine posts all transactions to memory.
ROLLBACK simply frees the memory, while COMMIT writes out the database changes in a
stream. If a system crashes during a transaction (LOGOUT--COMMIT), the recovery is
automatically handled by the TopSpeed driver the next time the affected file is accessed.

The Transaction Control File

The transaction control file (.TCF) is used to ensure that changes to more than one DOS
file, which are grouped into a transaction, either all happen or none happen. By default
the transaction control file has the name "TOPSPEED.TCF." The TCF driver string lets you
change this. See TCF for more information.
When any workstation finds a file which is in a partially committed state, and which was involved in a multi-file transaction, it needs to access the TCF file to decide what to do. The TCF file provides "atomicity"--a single (boolean) storage location which inndicates if a multi-file transaction committed or not.

Note that the .TCF file contains very little information; it just serves to coordinate multi-file commits. The actual rollback/commit data is stored in the data (.TPS) files.

How TopSpeed Transaction Logging Works

LOGOUT gives each transaction a unique id which it stores in the .TCF file. LOGOUT also stores the .TCF file name and transaction id in each data (.TPS) file which is updated, so that after a crash, the next time the file is opened the TopSpeed driver can find the .TCF file and do any necessary recovery. COMMIT removes the unique transaction id from the .TCF file.
To be effective, the .TCF file must be accessible when any files controlled by it are accessed. Therefore, you generally should not delete or move .TCF files. If a transaction updates network files, you should specify a transaction control file on the network.

It is not necessary to use the same TCF file for all transactions; however, we strongly recommend it. The consequence of there being several TCF files with various levels of accessibility (or of a deleted or overwritten TCF file) is that some of the files within a transaction might be updated and others left unchanged.

=============================================

Здравствуйте, коллеги!

Все таки решил до конца разобраться с работой
процесса транзакции на TPS-драйвере.

Сначала некоторые уточнения и дополнения к предыдущим
моим письмам по этой теме.

- Во время выполнения оператора COMMIT() физическая запись
данных в файлы производится поочередно в порядке, обратном
порядку их задания в операторе LOGOUT().

Все это происходит в четыре этапа:
1. Создается TCF-файл и в него записывается информация о таблицах,
участвующих в транзакции.
2. Данные, накопленные в транзакционном буфере,
записываются во ВСЕ таблицы в резервные(временные) страницы.
Некоторые особенности этих страниц будут описаны ниже.
3. Происходит модификация TCF-файла.
В чем она заключается - не разбирался, но это - единственная
модификация TCF-файла в рамках транзакции. Очевидно, что
при этом записывается информация об окончании этапа N2.
4. Записи из резервных страниц во ВСЕХ таблицах переписываются
в нормальные(постоянные) страницы. Резервные страницы при
этом не удаляются. Это произойдет лишь во время закрытия
таблиц оператором CLOSE().

Особенности резервных(временных) страниц, в случае прерывания
выполнения оператора COMMIT():
- до завершения этапа N3, резервные страницы НИКАК себя
не проявляют в дальнейшем.
- после завершения этапа N3 и до завершения этапа N4:
- если до транзакции таблица была пустой, то ВСЕ записи
в резервных страницах нормально читаются ВСЕМИ операторами
типа GET/NEXT/PREVIOUS;
если в таблице уже были записи, то резервные страницы
не видны.
- если до транзакции таблица была пустой, то при первом-же
выполнении оператора модификации типа ADD/PUT/DELETE
записи из резервных страниц переводятся в нормальные
а сами резервные страницы удаляются.
- при закрытии таблицы оператором CLOSE резервные страницы
просто удаляются.

- Автоматического восстановления таблиц НЕ ПРОИСХОДИТ!!!

- если выполнение COMMIT() прервалось во время
выполнения этапа N4, то ВСЕ таблицы открываются
нормально, но резервные страницы остаются на месте со
всеми последствиями, описанными выше.
Оператор CLOSE() удаляет резервные страницы.
При этом модификация одной таблицы НЕ ЗАТРАГИВАЕТ
другие таблицы, которые участвовали в транзакции!
Таким образом, если во время этапа N4 некоторые
таблицы уже были полностью обработаны, то их
"ОТКАТА" НЕ БУДЕТ НИКОГДА!

Вот так!!!
В транзакции участвовало несколько файлов, а их восстановление
происходит РАЗДЕЛЬНО!
Т.е., НИКАКОГО СОХРАНЕНИЯ ЛОГИЧЕСКОЙ ЦЕЛОСТНОСТИ ДАННЫХ
транзакция НЕ ОБЕСПЕЧИВАЕТ!

Хотя, нет, стоп! Не столь категорично!
- Логическая целостность обеспечивается на все 100% ТОЛЬКО
ДО выполнения оператора COMMIT().
- Крах ВО ВРЕМЯ выполнения оператора COMMIT() практически
не страшен до завершения этапа N3.
- Крах ВО ВРЕМЯ этапа N4, В БОЛЬШИНСТВЕ случаев,
приводит к НАРУШЕНИЮ ЛОГИЧЕСКОЙ ЦЕЛОСТНОСТИ данных!

Короче, остается лишь уповать на надежность оборудования
в том коротком промежутке времени, когда выполняется
этап N4 оператора COMMIT()!
И, соответственно, стараться делать обьем транзакций минимальным.
Хотя, как в таком случае соблюсти логическую целостность?!

И еще остается вопрос - на кой нужен TCF-файл!?
Если он реально НЕ ОБЕСПЕЧИВАЕТ связное восстановление
таблиц, участвовавших в транзакции!

Ау, коллеги, "близкие" к SV!
Возможно разработчики из SV опровергнут мои выводы
(очень хотелось-бы!), или, хотя-бы, дадут некоторые
разьяснения!?

Кстати! Во время открытия таблицы, которая участвовала в прерванной
транзакции, определяется факт наличия незавершенной транзакции!
Но никаких действий по ее "откату" НЕ ПРОИЗВОДИТСЯ!
Почему - не стал вникать - уж слишком там "наворочено".
Поэтому хотелось-бы и по этому поводу получить разьяснения
от разработчиков SV!

=============================
С уважением, Олег А. Руденко.