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

[Губин Игорь]

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

В природе существует.
В свободной раздаче - нет

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

В свободной раздаче - нет

Весьма и весьма грустно. Можно было бы попробовать как альтернативный вариант вместо терминального доступа.

[finsoftrz]

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

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

Игорь, а примеры можете привести. Ведь разница настолько велика, что это примерно как велосипед с автомобилем сравнивать. Если обязательно легальность нужна, то 75 долларов за 4 рабочих места не те деньги, на чем следует экономить... Возможно, пользователи просто не знают об этом. Были у нас несколько мелких организаций, которые на файл-сервере работали. Ушли с него, звонки на суппорт прекратились.

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

Да я не настаиваю Работа с logout/commit и без них сильно разные процессы. Если действительно интересна история вопроса, вроде на этом сайте были статьи Олега Руденко. Живого классика клариона...

[finsoftrz]

Впрочем, Олег иногда заходит на этот сайт, может увидит тему и прокомментирует. Мне не актуально, т.к. для отказа от кларионовских транзакций требуется довольно специфическая архитектура приложения. А после ухода с файлового сервера проблем с надежностью транзакций, в общем, особых нет. Я просто слегка удивился, вроде сто раз тему терли, и снова появляется. Правда, я тоже архивы clalist давненько не просматривал. А там такой пласт информации, многое актуально и сейчас...

[Губин Игорь]

Игорь, а примеры можете привести. Ведь разница настолько велика, что это примерно как велосипед с автомобилем сравнивать

По поводу перехода на терминальный доступ?
У меня есть кусок программы, в котором строится дерево из файла. В режиме файл-сервер с рабочей станции этот процесс может занимать до 10 минут из-за стандартных проблем виндов, после перехода на TSPlus, на том же самом железе, тот же процесс занимает секунд 5. Соответственно и проблем с разрывом связи, ошибками с записью в файл и т.п. стало на много порядков меньше.

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

Господа программисты - стоп !

Обсуждение темы свелось к известной фразе Марии-Антуанетты
«Qu’ils mangent de la brioche !» («Если у них нет хлеба, пусть едят пирожные!»).

Абсолютно нет никаких сомнений в преимуществах терминального доступа.
С описанием построения дерева непонятно зачем вообще открывать файлы на запись,
а при открытии на чтение разрушение файлов невозможно даже в теории (и работает на 10% быстрее).

Скорость построения будет быстрее ровно настолько, насколько данные с Вашего
HDD считываются быстрее, чем через сеть с HDD сервера ... и нет никаких гипотетических
"стандартных проблем виндов". Точнее проблемы есть, но здесь они вообще не в тему.

Вопрос был о том, можно ли как-то восстановить уже разрушенный файл TPS из прикладной
программы (например считав блоками данные и записать их в новый файл, как это делает TPSFIX).
Судя по всему - нет, так сделать нельзя. Жаль. Будем думать как прикрутить TPSFIX ....

[finsoftrz]

Скорость построения будет быстрее ровно настолько, насколько данные с Вашего HDD считываются быстрее, чем через сеть с HDD сервера ... и нет никаких гипотетических "стандартных проблем виндов". Точнее проблемы есть, но здесь они вообще не в тему.

Ну, как бы не совсем так. При работе на терминальном сервере данные оседают в кэше. Это хорошо видно на глаз. После перезагрузки сервера отчеты первый раз формируются медленнее, потом ускоряются. Это называется "прогрев кэша". Достаточно одному пользователю сделать обращение к базе данных. Ускорение при прогретом кэше субъективно почти на порядок. Поэтому сравнивать надо скорость чтения из оперативной памяти и скорость чтения с HDD+передача через сеть.

Вопрос был о том, можно ли как-то восстановить уже разрушенный файл TPS из прикладной
программы (например считав блоками данные и записать их в новый файл, как это делает TPSFIX).
Судя по всему - нет, так сделать нельзя. Жаль. Будем думать как прикрутить TPSFIX ....

Прикручивать tpsfix то прикручиваем, вот только стремно все это в руки пользователя отдавать. Ситуации могут быть разные. У нас 3 шага. 1 - запуск tpsfix с передачей ему имени файла и сообщением, чтобы пользователь там нажал все по умолчанию, 2 - копирование полученного выходного файла на место исходного, 3 - запуск процедуры верификации базы данных (проверка логических ссылок между таблицами и контрольных сумм по документам).
А вот если проблема случилась на приличной базе данных и простои в работе нельзя допускать, то придумана такая схема. Копируем битую базу. Восстанавливаем из копии и разрешаем работать только на ввод новых документов (принимать заказы, платежи и т.п.). На копии запускаем восстановление (в зависимости от обстоятельств вначале пробуем tpsfix, не получилось, накатываем лог или сразу лог), потом верификацию. Когда все восстановили и проверили, заливаем документы, которые успели ввести, в восстановленную копию и переключаем работу на нее. Как-то так.

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

Это называется "прогрев кэша".

Да, в принципе то же самое наблюдается и при работе на локальном компьютере или в локальной сети ... если конечно
это действительно сервер (установлена серверная Windows и достаточно RAM), а не самый ненужный компьютер в офисе с XP.
И кстати, этот кеш тоже источник проблем с БД, после фразы "Ой ! А это была кнопка RESET ?" Причем везде, и в терминале и локально.

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

Да, вот за это спасибо. Видимо придется придумать что-то на основании описанной Вами алгоритмики восстановления ...

[Губин Игорь]

С описанием построения дерева непонятно зачем вообще открывать файлы на запись,

Для построения того самого дерева
Но ты прав, мы отошли в сторону от темы

[Губин Игорь]

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

Муторно, но, в целом, вполне реально

[finsoftrz]

Это называется "прогрев кэша".

Да, в принципе то же самое наблюдается и при работе на локальном компьютере или в локальной сети ... если конечно
это действительно сервер (установлена серверная Windows и достаточно RAM), а не самый ненужный компьютер в офисе с XP.

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

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

что при файл-шаринге кэширование на уровне операционной системы не работает

Работает ! Это и визуально видно. Недавно я поднимал тему скорости доступа к файлам БД TPS при открытии из с доступом
запись / чтение. Результат был получен, но для тестирования как раз приходилось постоянно перезагружать компьютер и сервер,
для того, что бы убрать эффект кэширования из статистики замеров скорости доступа.

[finsoftrz]

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

PS. Я тут подумал. Если взять хороший скази-диск, поднять хорошую сетку (писали, что сейчас доступно сделать 20 гбит со стороны сервера и по 10 гбит со стороны станций), на сервер поставить не винду, то вполне скоростное решение для файл-шаринга в локальной сети можно получить. Скорее всего, стоимость такого решения и стоимость последующего владения будет выше, чем у терминальной системы, поэтому и мало кто с этим заморачивается...

[Admin]

Если взять хороший скази-диск

Говорите SAS (Serial Attached SCSI) т.к. чистый скази уже не производится.

[kreator]

PS. Я тут подумал. Если взять хороший скази-диск, поднять хорошую сетку (писали, что сейчас доступно сделать 20 гбит со стороны сервера и по 10 гбит со стороны станций), на сервер поставить не винду, то вполне скоростное решение для файл-шаринга в локальной сети можно получить. Скорее всего, стоимость такого решения и стоимость последующего владения будет выше, чем у терминальной системы, поэтому и мало кто с этим заморачивается...

Один знакомый поставил Linux в качестве файл-сервера, и туда 1С (ещё 7-я версия, там те же проблемы). Но что-то пошло не так, через пару недель слетел партишен. Хорошо догадался полный бэкап делать. Я в том смысле, что Винда работает, а неВинда требует дополнительных движений, в т.ч. платы за администрирование и т.д. Уж лучше терминал, хотя и решение не универсальное, ИМХО.