16 октября, вторник 17:05
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

СРОЧНО Тупиковые ситуации: "Ошибка 78 на операции ХХ"

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • СРОЧНО Тупиковые ситуации: "Ошибка 78 на операции ХХ"

    Буду благодарен, если кто-нибудь подскажет, как под Pervaisive, может ли возникать ошибка 78 На операции ХХ, если в конце примера (см. ниже) не будет строки FreeObj(@PayDocTTbl). Причем эта ошибка встречается на других машинах, где либо FreeObj(@PayDocTTbl) стоит, либо используется конструкция BeginTransAction....EndTransAction;
    Pervaisive конструкцию BeginTransAction....EndTransAction в нескольких транзакциях "разруливает" легко, а вот комбинированные ...????

    P/S На сервере во время возникновения ошибки, как правило, более 4-х транзакций (хотя это не точно).

    Плиз, если кто в курсе помогите!!!

    Пример:
    Tables
    PayDocT=PayDoc(noOpen); // первая магическая строка
    const coPayDoc=24; // Это - код таблицы PayDoc. Он содержится в словаре, его
    // можно узнать с помощью утилит AtBase или Ace.
    Formula
    {
    PayDocTTbl:=
    MakeTableByBuffer(GetPayDocBuffer); // вторая магическая строка
    // поскольку ранее вызванные формулы могли "засорить" PayDocB,
    // надо теперь очистить его:
    BufFillChar(PayDocTTbl,coPayDoc); // третья магическая строка
    // благодаря магическим строкам, мы можем заносить значения в PayDocB
    PayDoc.UserCode:=1000; // Эта строка эквивалентно CondUserCode(1000);
    PayDocT.BatNum:=1;
    // было бы бессмысленным написать здесь: PayDocBuf.DbAcc:='123456',
    // поскольку функция Cond перепишет значение одного из своих параметров
    // поверх текущего значения DbAcc
    if not Cond('467001','467002',1000,'000') goto exit_label;
    :exit_label
    FreeObj(@PayDocTTbl); // четвертая магическая строка
    }

  • #2
    Неужели ни у кого не возникала ошибка 78 Бтрив обнаружил тупиковую ситуацию на операции 3(например 3)???

    Вопрос а кто-нибудь пользуется работой с файлами как в примере? Если да то как успехи?

    Комментарий


    • #3
      Не знаю истиной причины ошибки, но позволю себе немного поучить (да простят мне читатели форума этот грех)
      - не стоит переопределять константу (coPayDoc), если она уже определена в "Кворуме"
      - ни в одном кворумовском отчете не используется ф-ия BufFillChar (я не нашел). Лучше все-же инициализировать поля таблицы напрямую

      Комментарий


      • #4
        ВНИМАНИЕ:

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

        "- ни в одном кворумовском отчете не используется ф-ия BufFillChar (я не нашел)" - по этому поводу трудно с Вами спорить, но если поискать, то найдете...

        "Лучше все-же инициализировать поля таблицы напрямую" - у нас куча прог, которые это используют...

        Ну а чем на прямую лучше? М.Б. примерчек скинете?

        Ну если совсем нет времени, то спасибо и на этом...

        Комментарий


        • #5
          BufFillChar просто "обнуляет" поля в буффере таблицы. То-же самое можно сделать написав
          PayDoc.docDate := Date(0);
          PayDoc.OperNym = 0;
          ....
          ....
          ....

          И так по всем полям(Я именно иак и делаю).
          Это необходимо для сделать перед вставкой записи в таблицу.

          М.Б. примерчек скинете? Самое большое кол-во примеров в каталоге PayDoc.CNS. Просто надо сделать контекстный поиск на интересующую Вас ф-ию.

          "Вылетание" при использовании FreeObj я тоже наблюдал в одном из своих отчетов на Btrive. Боролся с помощью шаманского бубна :-))

          Комментарий


          • #6
            Вылетание" при использовании FreeObj я тоже наблюдал в одном из своих отчетов на Btrive. Боролся с помощью шаманского бубна :-))

            У нас Pervasive 2000, не давно сменили...

            У нас есть проги использующие FreeObj, а есть не использующие...

            Как мне кажется вылетают те, где стоит FreeObj и BufFillChar, когда на Первайсиве куча транзакций...

            Я вот не понимаю чем плохо BufFillChar...
            И когда не ставиш FreeObj - это кажется плохо...

            К тому же Кворум закрывает таблицы только при выходе из арма...

            Меняли сегодня настройки Первайсива м.б. поможет...

            Если есть соображения, то поделитесь...плиз.

            Комментарий


            • #7
              УВЫ настройки сервера не помогли...

              Комментарий


              • #8
                Неужели ни у кого не возникала ошибка 78 Бтрив обнаружил тупиковую ситуацию
                Да, Программер, сочувствую...
                Возникала эта ошибка, возникала... У меня вот только 5 минут назад возникла, когда я запустил в двух разных экземплярах АРМа Paydoc одновременно процедуру автоматической квитовки выписки с кор.счета в одном, и процедуру приема макета из РКЦ - в другом.
                Но возникает она в нормально работающем Кворуме уж очень редко и при достаточно специфичном сочетании условий... Так что особо сильно не напрягает.
                А регулярное и частое появление такой ошибки... ну не знаю, я такого не видел.
                На самом деле "тупиковая ситуация" - это действительно тупиковая ситуация, т.е. ситуация, когда измененные данные не могут быть сохранены в таблице потому что она кем-то нафиг заблокирована. Надо копать не в сторону того правильно или неправильно работает FreeObj, а смотреть на ситуацию в системе в целом.
                Вряд ли это сильно поможет, но на всякий случай кину несколько наводящих вопросов:
                Стоят ли сервис-паки к серверу PervasiveSQL 2000 (нужно минимум SP3) ?
                Какая версия Кворума ? Вряд ли сильно старая, но вдруг ? АРМы на базе Атлантиса 1.1, которые входили в версию 6.х, имели определенные проблемы с некоторыми версиями Первэйсива.
                Нет ли в системе явно узких мест, например очень мало памяти на сервере, или какую нибудь ответственную функцию по регистрации больших пачек документов возложили на 386 машинку ?
                А может быть какая-то проблема в логике использования именно приведенного алгоритма ? Может быть он вызывается из какой-то процедуры, которая в этот момент как раз таблицу Paydoc держит ?
                Ну не знаю, что еще предположить...

                Комментарий


                • #9
                  У нас тоже возникала 78-я, но очень редко. Обычно просто - файл заблокирован на операции ....
                  В последнее время мучаемся с другой проблемой - вставляем платежки из Интернет-банка (через ODBC-интерфейс). До появления таблицы DocsByShifr все было более или менее, а вот уже почти год мучаемся.
                  Вставки идет в транзакции в таблицы PayOrder/MemOrder и PayOrCom и DocsByShifr.
                  В последние 2 вставлять нужно OperNum из PayOrder/MemOrder, который получается после insert и select Max(OperNum) from PayOrder (а как иначе?)
                  Так вот, в DocsByShifr и в PayOrcom почему-то кладутся записи с OperNum=0. При этом транзакция подвисает, другие транзакции накапливаются (до 8 штук по монитору). Лечится удалением через atbase записи с OperNum=0 в DocsByShifr - транзакция откатывается, дальше сервер работает нормально.
                  Как бы этот момент обойти?
                  С уважением,
                  Егор

                  Комментарий


                  • #10
                    Egor_viking Egor_viking Egor_viking
                    Было у нас подобное при смене верси...
                    Написали свою прогу вставки записей в таблицу DocsByShifr и теперь с этим все ОК.

                    Комментарий


                    • #11
                      Походу у нас "Золотая корона" вешает Первайсив...
                      Когда в "Золотая корона" никто не работает - ТУПИКОВЫХ СИТУАЦИЙ НЕ ВОЗНИКАЕТ, тьфу-тьфу-тьфу...

                      Комментарий


                      • #12
                        Программер, Egor_viking
                        Мдааа... Ну вы, ребята, извините, слегка мазохисты, имхо... Сначала залезут напрямую в БД Кворума на запись внешними прогами, а потом удивляются, что возникают тупиковые ситуации и ссылочная целостность рассыпается...

                        Мое глубокое ИМХО, что доступ к бтривовской БД Кворума внешними средствами, через ODBC, Titan и т.п. должен быть исключительно readonly ! А любая запись, тем более если затронуты несколько таблиц со взаимными ссылками, должна делаться ТОЛЬКО средствами Атлантиса.
                        В случае с Интернет-Банком я бы именно так и сделал. Выписки бы для клиентов формировал бы через то же ODBC в режиме readonly, а платежки закачивал бы в Кворум через файловый интерфейс, используя какую-нибудь адаптацию АРМа Qhost, скажем. Задержка была бы всего несколько лишних секунд, зато функции Payor/Memor и SetAddParam_1256U отрабатывали бы в одной транзакции, и проблем со ссылочной целостностью бы не было.
                        А в случае с ведением карт-счетов (я так понял у Программер они в Кворуме ведутся ?), бтрив имхо в принципе не подходит - если все писать грамотно, то не та скорострельность получится, а если не грамотно - то тогда и появляются всякие тупиковые ситуации. Может подумать и на оракловую версию перейти ?

                        Комментарий


                        • #13
                          Может подумать и на оракловую версию перейти ? Гозаздо риятнее работать.

                          Комментарий


                          • #14
                            Может подумать и на оракловую версию перейти ? Гозаздо риятнее работать.

                            P.s. Кто бы денег та дал на это????

                            Комментарий


                            • #15
                              Программер P.s. Кто бы денег та дал на это????
                              Дык проблема понятна. Я ж не для того отвечал чтобы пальцЫ погнуть, мы сами на Первэйсиве работаем.
                              Просто если действительно нужна качественная и быстрая интеграция с внешними программами, изменяющими основную БД, и вариант решения через файловый обмен с каким-нибудь сервисным АРМом на Атлантисе (вроде QHost) не подходит, то бтривовский Кворум под это дело действительно не заточен - те или иные проблемы почти гарантированы. Так что остается или решать проблемы самостоятельно находя компромиссы, или менять софт.
                              ИМХО, конечно.

                              Комментарий

                              Пользователи, просматривающие эту тему

                              Свернуть

                              Присутствует 1. Участников: 0, гостей: 1.

                              Обработка...
                              X