Спасти TPS список из программы ...

Игорь Столяров

Привет всем !

Эпизодически возникают проблемы с TPS файлами, см. рисунок:

Причины возникновения проблем - понятны. Лечим прогонкой списка через TPSFIX. Можно через командный BAT файл.
Вопрос в другом. Можно ли как-то TPS файлы с такими ошибками структуры восстанавливать из кода программы ?
Может быть есть какие-то скрытые функции в Clarion API ?

Из того, что видел в виде шаблонов - это различные манипуляции вокруг PACK() и Build(), что в данном случае
не помогает. Причем абсолютно.

Заранее спасибо за наводку, может быть кто-то видел реализацию такой "лечилки" TPS списков ...

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

kreator

SV пишет, что TPS - надёжная система, сама типа восстанавливается. Почитай раздел в хелпе "Repairing Data Corruption in TopSpeed/Clarion Files". Хотя, наверно это и не секрет. А вдруг?

gopstop2007

kreator писал(а): ... сама типа восстанавливается.

Хотелось бы чудодейственной регенерации TPS файла

, но увы опять используя TpsFix...

Игорь Столяров

gopstop2007 писал(а): но увы опять используя TpsFix...

Да. Что-то вроде этого. В новый год принято ходить логическим путем. И мы пойдем.
TPSFIX может читать записи (блоки данных или что-то вроде этого) из коцнутого файла без GET и SET/NEXT.
Значит есть некое API которое содержит этот функционал. Вопрос в том как к нему подлезть.
Наверняка ведь как-то можно ....

gopstop2007

согласен, но SV считает tps "не убиваемыми" и они считают, что для этого tpsfix + command хватает... кстати когда то пробегали шаблоны tps repair и криков потребности чего то более не слышно

Игорь Столяров

gopstop2007 писал(а): шаблоны tps repair

Да, я написал об этом ... может быть есть еще, что-то ... но те что я видел - это просто Pack() & Build() списков.
Бесполезный прибамбас. Ключи, кстати, в TPS файлах летят действительно крайне редко.
А вот разрушить структуру файла достаточно просто. Например при записи по сети списка с достаточно большой
длиной записи меняем IP адрес сервера и инициируем таким образом обрыв сетевого подключения. Вероятность разрушения 50%.
Или вырубание компьютера при нескольких открытых списках на запись и записи в них информации. Вероятность разрушения до 10%.
И это без кэширования через Stream() ...

Игорь Столяров

Угу. Судя по всему современная наука ответ на этот детский вопрос не знает ...

Shur · Сообщение **Shur** » 09 Январь 2016, 0:10

Игорь Столяров писал(а): Например при записи по сети списка с достаточно большойдлиной записи меняем IP адрес сервера и инициируем таким образом обрыв сетевого подключения. Вероятность разрушения 50%.Или вырубание компьютера при нескольких открытых списках на запись и записи в них информации. Вероятность разрушения до 10%.

Игорь, прошу прощения, просто никогда не пользовался TPS промышленно по сети (поэтому и тема для меня как бы "непрочувствованная"), а используете вы у себя LOGOUT()...COMMIT? Или это не никак не влияет на порчу файлов данных?

Игорь Столяров

Shur писал(а): а используете вы у себя LOGOUT()...COMMIT?

Да, конечно. На описанную ситуацию с разрушением структуры TPS файлов это никакого влияния не оказывает ...
Что в общем-то вполне ожидаемо - транзакция и ее откат - это несколько другое ...

Наверно надо сказать, что TPS структура достаточно надежна для файл-серверной БД, но хотелось бы конечно
иметь возможность разруливать возникающие проблемы из прикладной программы (например запуск с параметром /RECOVER) и т.д.

finsoftrz

Игорь Столяров писал(а):
Shur писал(а): а используете вы у себя LOGOUT()...COMMIT?
Да, конечно. На описанную ситуацию с разрушением структуры TPS файлов это никакого влияния не оказывает ...
Что в общем-то вполне ожидаемо - транзакция и ее откат - это несколько другое ...

Наверно надо сказать, что TPS структура достаточно надежна для файл-серверной БД, но хотелось бы конечно
иметь возможность разруливать возникающие проблемы из прикладной программы (например запуск с параметром /RECOVER) и т.д.

Хм, у меня другая информация. Разрушению подвергаются tps-файлы при использовании logout/commit. Без них вроде и ломаться там нечему. Была как-то подробная статейка на эту тему. Проблему решаем просто - уход с файл-серверного режима на терминальный (при наличии tsplus даже не понимаю, нафига нужен файл-сервер) плюс лог, из которого можно накатить изменения на последнюю резервную копию базы данных и восстановить все на момент сбоя. На терминальном сервере можно тоже базу повредить, если жестко вырубить питание в самый неподходящий момент...

Игорь Столяров

finsoftrz писал(а): уход с файл-серверного режима на терминальный

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

Полностью согласен. Но к сожалению - не всегда возможно реализовать технически ...
Что касается, LOGOUT / COMMIT - то как без них выполнять групповое изменение списков, если что-то в середине пойдет не так ?
Да, и как я написал ранее - списки валятся и отслеживанием транзакций и без них. Без них хуже - т.к. операция выполняется
значительно дольше и вероятность попасть на то же обрубание компьютера - значительно выше ... Просто математика, ничего личного.

Shur писал(а): просто никогда не пользовался TPS промышленно по сети

При использовании TPS в режиме файл-сервер возможны значительные тормоза при усиленном обращении к файлам.
Logout позволяет гарантировать, что, если пьяная уборщица выдернет провода, база будет нормальной, но в состоянии до logout.

Терминальный доступ, действительно, снимает массу проблем при работе с тпс по сети, проверено жизнью. Ну, или IPDRV

finsoftrz писал(а): Разрушению подвергаются tps-файлы при использовании logout/commit

А в какой момент? Если только когда закрывается транзакция?

Игорь Столяров

Губин Игорь писал(а): Ну, или IPDRV

А сабж существует для C10 в природе вообще и у нас в частности ?