Восстановление удаленных записей (TPS)

Clarion, Clarion 7

Модератор: Дед Пахом

Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
Ответить
Гость

Сообщение Гость »

Добрый день!

Собственно сабж.

с55

Hlp <hlp@mail333.COM>

(Добавление)

Собственно - ДА! :D

--
Best regards,
Alexander mailto:clalists@partizansk.com

Таки да? IMHO - нет.

С уважением,
В.Смелик.

:lol: Так и знал!

Это был вопрос - возможно ли восстановление удаленных записей в TPS.

Hlp
Собственно - ДА! :D
Интересно, как и чем, с учетом того, что RECLAIM и PACK не поддерживаются,
поскольку файл автоматом упаковывается сразу после удаления записи.

WBR, Nick Tsigouro. MailTo:Nick@arsis.ru
Написал: ClaList(2)
Гость

Сообщение Гость »

TPS-драйвер НЕ поддерживает маркировку удаленных записей
и их исключение из работы. Поэтому в нем реализовано
НЕМЕДЛЕННОЕ ФИЗИЧЕСКОЕ удаление записей.
В основном, связано это с тем, что структура TPS-файла
очень напоминает структуру обычного ключа, а хранение
в ключе неиспользуемой записи - не предусмотрено теорией.

Так что, собственно - НЕТ.

=============================
С уважением, Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com

Библиотека DynaLib
http://dynalib.narod.ru

(Добавление)

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

WBR, Nick Tsigouro

Не знаю, насколько преследовались столь благие цели.
Есть подозрение, что организация страничного формата
хранения с b-деревьями индексов проще организуется
для случая, не требующего хранения удаленных записей.
Т.е. запись поверх - свойство системы.
А вот почему был выбран страничный формат... Может,
как раз для создания "непрерывно работающих ...".

С уважением,
В.Смелик

А может у SV есть планы организации постраничной блокировки
TPS-таблиц при транзакциях!?
Представь, насколько это было-бы удобно в сетевой работе!

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

=============================
С уважением, Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com

Библиотека DynaLib
http://dynalib.narod.ru

(Добавление)

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

Вот за это им - огромное СПАСИБО!

Кто обслуживал чужие clipper'нутые программы на 286-х и 386 машинах, помнит,
какими искренними ;D словами сопровождалось радостное сообщение "А теперь
мы поиндексируем ВСЕ ваши-наши базы!!!" :D

Интересно, как и чем, с учетом того, что RECLAIM и PACK не поддерживаются,
поскольку файл автоматом упаковывается сразу после удаления записи.

Да нет, ты не понял - это я вечером, после трудового дня, позубоскалил немного
;)
Больно уж вопрос хороший :) И, главное - формулировка КАКАЯ! Ну никак
невозможно не понять! ;D

P.S. Ответ д.б. "НЕТ". IMHO ;)

P.P.S. Я не злой, я просто был "устамши"... ;))))

:D Так и знал!

:rotate:

Это был вопрос - возможно ли восстановление удаленных записей в TPS.

Ааааа, так _вопрос_ ТАКИ БЫЛ?! :gigi:

--
С уважением,
Степанец Александр Валентинович.
Написал: ClaList(2)
Гость

Сообщение Гость »

А может у SV есть планы организации постраничной блокировки
TPS-таблиц при транзакциях!?
Представь, насколько это было-бы удобно в сетевой работе!
Вряд-ли это возможно. Я слабо представляю себе, как уйти от клинча при такой
блокировке.

WBR, Nick Tsigouro

В текущей версии TPS-драйвера для блокировки таблицы
операторами LOCK/LOGOUT используется логическая блокировка
средствами САМОЙ ОС через функцию WinAPI LockFile.
Эта функция допускает блокировку ПРОИЗВОЛЬНОГО участка
ЛЮБОГО файла. При чем, в одном файле можно заблокировать
любое кол-во таких участков.
TPS-драйвер блокирует сразу ВСЕ пространство этого файла.

Таким образом, я не вижу большой разницы если вместо
блокировки ВСЕГО файла будет производится блокировка
только ЗАДАННОГО УЧАСТКА этого файла. А именно участка,
занятого обрабатываемыми страницами.

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

Хотя, имхо, коли есть такая возможность, можно было-бы
дать доп.форму операторов LOCK/LOGOUT для блокировки отдельных
записей файла и что-то типа блокировки для добавленных
записей. В последнем случае, сам файл блокировать не надо,
а просто включить стандартный механизм транзакции с
накоплением изменений в памяти и последующей потоковой
выгрузкой в файл при ее завершении.

Я просто файнтазирую, но представь насколько это было-бы
удобно! Разом снялись-бы проблемы с одновременным доступом
к одной записи, обработкой отца и его деток-внуков.
Т.е. в любом случае, алгоритм входа в форму был-бы типа:

Код: Выделить всё

DocsTran &TRANSACTION

  Loop
      ! Начало новой транзакции.
    DocsTran &= BEGINTRAN(Docs,Moves)
      ! Или можно так:
      ! DocsTran &= NEW(TRANSACTION)
      ! DocsTran.Init(Docs,Moves)
      ! Хотя первый вариант мне лично больше нравится
    if DocsTran.ErrorCode() then Break.
      ! Блокируем текущую запись файла документов
      ! Можно предусмотреть форму этого метода, когда
      ! можно не указывать последний параметр - в этом случае
      ! блокировке подлежит запись, считанная последней -
      ! по аналогии с операторами PUT/DELETE.
    DocsTran.LOCK(1,Docs,Pointer(Docs))
    if DocsTran.ErrorCode() then Break.
      ! Блокируем его деток, если есть
    Clear(MOV:Record,-1); MOV:Doc_Ndx = DOC:Index
    Set(MOV:Doc_Key,MOV:Doc_Key)
    Loop
      Next(Moves)
        ! Обработку ошибок чтения опускаю
      if ErrorCode() OR (MOV:Doc_Ndx <> DOC:Index) then Break.
      DocsTran.LOCK(1,Moves,Pointer(Moves))
      if DocsTran.ErrorCode() then Break.
    .
    if DocsTran.ErrorCode() then Break.
  .
  if DocsTran.ErrorCode()
     Message('Невозможно начать редактирование документа!')
     do ProcedureReturn
  .
Если успешно заблокировали ВЕСЬ документ, то дальше СПОКОЙНО
работаем как с формой самого документа, так и с его записями -
существующие записи уже никто НЕ ТРОНЕТ, а добавляемые дочерние
записи просто еще не появятся в самой таблице - работает
механизм транзакции с накоплением изменений в памяти!

При выходе из формы:

Код: Выделить всё

ProcedureReturn Routine
  ...
  if (LocalResponse = RequestCancelled) OR DocsTran.ErrorCode()
     DocsTran.RollBack()
  else
     DocsTran.Commit()
  .
  Dispose(DocsTran)
И все!!!
Не нужны никакие временные очереди с ручным заполнением,
последующей синхронизацией и удалением добавленных деток
в случае отката!

Кстати!
Сейчас вот подумал, а как решаются подобные вопросы
на SQL-серверах со страничной/построчной/поколоночной
блокировками?
К примеру, если я в рамках транзакции "напоролся" на
запись, заблокированную другой транзакцией - что будет?
"Обломится" транзакция или сработают какие другие механизмы?

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

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

WBR, Nick Tsigouro
Вот именно в этом случае и возникает опасность клинча. Ты заблокировал
какие-то блоки, я заблокировал другие. Теперь тебе нужно то, что я уже
захватил.
...и в этом случае сервер возвращает что-то типа EDEADLOCK...

--
Best regards,
Maxim Yemelyanov,
Enigma Soft Company
phone: +380 572 177977
WEB: http://enigmasoft.com.ua
e-mail: clalist@enigmasoft.com.ua
ICQ: 12253836

(Добавление)

BTRIVE 6.15 имеет страничную блокировку записей.
PERVASIVE 2000 по моему уже имеет блокировку по записям.

С уважением, Ставич Олег
Укрсиббанк г.Харьков
oldstav@ukrsibbank.com
Вот именно в этом случае и возникает опасность клинча. Ты заблокировал
какие-то блоки, я заблокировал другие. Теперь тебе нужно то, что я уже
захватил. Ты ждешь, пока я освобожу. Если мне не понядобятся твои блоки, я
благополучно завершу свою транхакцию, и ты продолжишь работу, а если мне
понадобятся твои, то будем висеть и в лучшем случае ждать таймаута.
Хм... В приведенном тобою случае я не вижу совершенно
никакой разницы в сравнении с текущим положением -
сейчас аналогично - я блокирую один файл, ты блокируешь
другой. Если мне понадобится твой файл, то я так-же
"отвалюсь" по таймауту с ошибкой!
Я же в предыдущем письме привел вариант (и не надуманный -
а реальный!), когда такая выборочная блокировка была-бы
очень полезна.
А при поточной модификации/удалении записей файла самым
лучшим, естественно, будет именно полная блокировка
этого файла.

=============================
С уважением, Олег А. Руденко
Написал: ClaList(2)
Ответить