Аналогично...
Т.е. такая ситуация с С55 действительно имеет место не у мня
одного ?
[CWC21]
CLATMP=C:\WINDOWS\Temp
Раздел в [CWC21] Win.ini создается специально для трайвера бд
Clarion?
Можно ли также в Win.ini создавать такой раздел и параметр для Win2000/XP или надо лезть в реестр?
можно ли это "вшить" непосредственно в код программы, опуская определение папки WindowsTemp (по API с этим проблем нет)?
Лог транзакции для ТПС ведется в памяти, для ДАТ на диске...
Говорят, что ДАТ более надежен (не в плане криптования)
Т.е. теоретически получается, что раз транзакции для ТПС ведутся в памяти, а не на диске, то в сети ТПС будет вести себя стабильнее?
Буду рад узнать мнения по этому поводу ,
Сергей
(Добавление)
компилирование этой же программы на C5507 (неважно на оригинальных Lecacy-Tpl или на ШВС) вызывает частые блокировки файлов (5-я ошибка ) и транзакционные ошибки (48)
Зря! Имхо - не стоит переводить на C55 проекты, активно работающие с БД! Сам уже сколько мучаюсь с "капризами" менеджера потоков C55 - а обратно, к сожалению, уже никак!
Причем такие вещи, в основном, проявляются именно при сетевом использовании программы: когда несколько пользователей запускают один и тот же EXE и соответственно обращаются к одним и тем же файлам.
Минутку! Если файлы открываются в Share-режиме и другие станции не используют эти файлы в транзакциях в данный момент, то проблемы с открытием (ошибка 5 - Access Denied) таких файлов могут быть только если один или несколько открываемых файлов использовались в последней "рухнувшей" транзакции.
Другое дело, если открываемый файл в данный момент используется какой-либо станцией в транзкации - тогда, да - для драйвера 'CLARION' это стандартное поведение.
В отличие от, например, драйвера 'TOPSPEED', который допускает чтение заблокированных файлов.
- одинаков ли внутренний механизм транзакций Dat-овских Clarion-файлов у С5 и С55
Практически - да. Есть лишь некоторые внутренние ньюансы, связанные со слишком большой долей участвия в этом менеджера потоков C55. Хотя, именно
ЭТО и является основной причиной большинства проблем C55!
- когда выполняется транзакция, судя по создающемся после "косяков" файлам <имя файла>.log в папке где находится exe-шник создается файл <имя exe>.tr$ Вообще эти *.tr$ должны быть у каждого пользователя свои или одни на всех (может в этом и кроется проблема?)
Файл TR$ должен быть у каждого пользователя свой - обычно в темповом каталоге сетевой станции.
Он содержит типа "образа" текущей транзакции.
Естественно, что с разных станций могут быть запущены РАЗНЫЕ (по составу файлов) транзакции. Если положить файл TR$ в общий каталог - будут большие проблемы с транзакциями. Естественно, это относится ТОЛЬКО к драйверу 'CLARION' - у 'TOPSPEED' несколько другая логика транзакций и там, наоборот, файл "образа" транзакций должен лежать именно в общем сетевом каталоге. Желательно, и лучше всего, в каталоге с файлами рабочей БД. Как, собственно, и поступает по-умолчанию драйвер 'TOPSPEED'.
- какую пользу можно извлечь из этих log-ов
Огромную!!! Именно в них хранятся все изменения, производимые с одноименным файлом БД во время последней транзакции. Т.е., естественно, во время транзакции их трогать не следует! Но, если транзакция "рухнула", и по каким либо причинам не сработал "откат" или его отработка невозможна, к примеру из-за испорченного TR$-файла, то эти LOG-файлы можно "подсунуть" одной полезной утилитке, которая сама произведет "откат" по информации из этих файлов.
Отсюда, кстати, вывод - нормальный "откат" возможен ТОЛЬКО с той рабочей станции, на которой и произошел "крах" последней транзакции! Так как именно на этой станции и находится TR$-файл с образом "рухнувшей" транзакции.
Что-же касается вышеупомянутой утилитки, то она, в свое время, была очень популярна в Кларион-тусовках!
Возможно и сейчас ее можно найти в архивах общедостуных Кларион-серверов. Ее автор - Алексей Соловьев, который, кстати, насколько я знаю, сейчас "сочиняет" Clarion-RTLв SV. Распространялась она в виде исходников для CPD2.1 и CDD30. Но были и уже готовые EXE-файлы.
ОЧЕНЬ полезная утилитка!
Из своего опыта могу сказать, что в подавляющем большинстве случаев нормальный "откат" производился именно по LOG-файлам.
- при работе в сети, что лучше делать:
размещать exe на рабочей станции, объявлять переменные имена файлов и указывать путь к серверу или хватит один exe-шник на всех. Как это влияет на скорость и надежность ?
Размещение EXE-файла влияет ТОЛЬКО на скорость его подгрузки на рабочие станции, что не является критичным для современного железа. Как локального так и сетевого.
Хотя, знаю, есть любители выигрывать ничтожные доли секунд путем размещения всего дистрибутива на каждой локальной станции с изобретением сложных и, имхо, ненадежных механизмов синхронизации изменений дистрибутива!
и если выбирать между TPS и DAT, что же все-таки предпочтительнее в этом случае (понимаю, конечно, что это не самый оптимальный вариант, но что "лучше из худшего"),
Трудно сказать! Относительно скорости работы - лучше, естественно, TPS. Особенно заметно на транзакциях - выигрышь в скорости ~5-10 раз!
Относительно надежности - имхо, лучше - DAT.
У него, в подавляющем большинстве случаев, могут быть проблемы только с ключами, которые элементарно перестраиваются. По крайней мере, я в своей практике еще ни разу не сталкивался с проблемами DAT-файлов из-за которых терялись данные!
А вот у TPS - практически каждый "срыв" транзакции влечет за собой какой-либо сбой во внутренней структуре заголовка всего файла или заголовка страницы или заголовка записи. И, как следствие, после восстановления такого файла FixTPS-ом запросто можем потерять часть данных в разрушенных страницах!
Грубо говоря, если прога типа "поставил и забыл", то лучшим вариантом является DAT-файлы с необходимым инструментарием восстановления ключей и оборванных транзакций, оформленных в виде удобного, для конечного пользователя, интерфейса.
Если нужна скорость при массовых модификациях БД и можно обеспечить квалифицированный присмотр за прогой, то - ставь TPS. В этом случае от админа требуется:
- вести грамотный бэкап БД (лучше несколько раз в день)
- уметь работать с FixTPS и TopScan-ом.
- грамотно организовать механизм "технологических" перерывов, что-бы можно было их использовать в случае порчи БД.
Ну и сама прога, естественно, должна иметь минимальный набор утилит для проверки логической целостности данных, их восстановления и, в случае необходимости, уметь производить выборочное восстановление записей разных таблиц из архивных копий. Дело в том, что иногда полный откат БД до предыдущего контрольного бэкапа невозможен по ряду причин! Именно в этом случае - сначала проверочным блоком определяем проблемы в восстановленном после ошибки файле и, при необходимости, восстанавливаем часть данных из архивной копии.
Ну и, естественно, если предполагается активное использование БД с большого кол-ва сетевых станций и есть предпосылки к ее активному росту (как в плане кол-ва записей, так и в плане физического размера файлов), то, имхо, следует задуматься о переводе БД на SQL-сервер.
вопрос к "Арсису": быть может ввиду того, что Dat-формат все-таки старый, то может в C55 он уже недостаточно отлажен.
Еще раз - основные проблемы в C55 связаны именно с "косяками" его менеджера потоков!
=============================
С уважением,
Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com
Библиотека DynaLib
http://dynalib.narod.ru
Переходи на терминалы, у меня C5.5F ШВС, TPS, одновременно до 40 пользователей за 2 месяца ни одного падения баз(правда и до перевода с CPD2.1, за 2 года только раз все рухнуло, когда свет обрубили, а у UPSника на сервере аккумулятор помер, не уследили)-:). Да и не надо никаких спецзнаний (типа SQL).
"
Дмитрий Гудков" <
gudkov_net@mail.ru>
Написал: ClaList(2)