Joined: 17 Mar 2003 Posts: 357 Location: Гусев Сергей Александрович Occupation: Сисадм Interests: Нижний Новгород
Posted: 19 Feb 2004 10:47 Post subject: Вопрос к И-С или как перехлестываются проводки-2 (+)
Вновь обращаюсь к разработчикам системы БЭСТ-4 со старой проблемой, носящей перемежающийся характер.
С начала этого года мои бухи уже второй раз сталкиваются с одной неприятной проблемой: если в одном и том же предприятии один бух вводит информацию по авансовым отчетам (в Кассе), а второй вводит информацию по банковским документам, то с некоторой вероятностью у них "перехлестываются" проводки, т.е. по истечению некоторого времени один бух видит у себя в авансовом отчете проводку от банковского документа, а другой соответственно от авансового отчета.
По словам тех же бухов, данная проблема у них случалась и раньше, причем неоднократно (а БЭСТ стоит у нас с 1994 года), и не всегда она была именно в такой связке (авансовые отчеты - банковские документы), иногда склад-склад (т.е. два буха вводят информацию по складу, после чего замечают у себя чужие проводки).
Вообще эта проблема крайне неприятна, т.к. если вовремя не заметить эти "левые" проводки, то потом их можно вообще не найти в балансе со всеми вытекающими последствиями. Кроме того, наличие данной проблемы разработчиком не подтверждается, т.к. она носит случайный характер и воспроизвести ее крайне сложно.
Хотелось бы выслушать комментарии разработчиков по данному вопросу. Возможно стоит сменить вариант поставки на BMOD?
Версия, на которой зарегистрирована последняя проблема 4.10.01/015, CMOD, сервер баз данных W2KS, операционная система рабочих станций W98, все рекомендации по настройке соблюдены.
У нас сейчас Бэст4 10.01 BMOD. Проблема с проводками была на всех версиях и на СMOD и на XMOD, и сейчас бывает несколько случаев в месяц.Причем чаще всего Касса и Банк "любят объединятся".Причин наверно несколько, одна из них - плохая сетка.Еще было замечено, что это зависит от скорости работы Буха на ПК.Чем больше скорость тем чаще ошибка возникает. Выявляем такие ситуации с помощью различных сверочных ведомостей в АРМах и контроля счетов в Гл.бухе.
Joined: 17 Mar 2003 Posts: 357 Location: Гусев Сергей Александрович Occupation: Сисадм Interests: Нижний Новгород
Posted: 19 Feb 2004 13:31 Post subject:
Quote:
Причин наверно несколько, одна из них - плохая сетка.
Убейте но не пойму, при чем тут "плохая сетка". И что значит "плохая" - плохих пакетов много что ли? У меня даже коллизий нет, т.к. тачки в бухгалтерской подсетке через управляемый свитч подключены, кабели и прочие розетки 5 категории, длина самого длинного кабеля до свитча не более 20 метров (комната одна однако). Даже если какая карточка свихнется, свитч ее отсечет. К тому же ну никак я не пойму, как плохие пакеты могут повлиять на ошибки блокирования или позиционирования.
Я так думаю что это вам И-С рассказку про плохую сетку рассказал, дабы перевести стрелку с больной головы на здоровую. У нас у одного из клиент-банков постоянно выписка расходящаяся приходит, так тамошние технари любят песни петь, что у нас плохая телефонная линия (у нас цифровая) и выписки по дороге искажаются и документы теряются. У меня даже бухи смеются над такими рассказками...совести грубо говоря нет у их авторо
Можно добавить к вышесказанному, то, что при наличии задвоения проводок на документ, в документе видна только одна проводка, которая завязана через системный номер. В книге операций же обе проводки просматриваются и ссылаются на один и тот же документ.
Я тут не говорю откуда появляются задвоения проводок, а о том, что они поздно обнаруживаются.
Joined: 17 Mar 2003 Posts: 357 Location: Гусев Сергей Александрович Occupation: Сисадм Interests: Нижний Новгород
Posted: 20 Feb 2004 12:51 Post subject:
Жаль, что нам не удалось послушать начальника транспортного цеха (т.е. И-С). И непонятно чего делать-то нам, сирым?
Рассказываю быль. Пользовали мы в одной конторе АТС Merlin Legend и к ней телефоны производтства AT&T. У них печатные платы были сделаны на какой-то пленке типа лавсановой, и по истечении нескольких лет на двух типах таковых аппаратах начались пробои этой самой пленки с замыканиями дорожек. Мы их спиртом мыли, антистатиком прыскали, но все напрасно - как наступает лето и влажность, пробивает лавсан к чертовой матери и телефон вырубается. Позвонили в представильство AT&T, но там даже слушать не захотели - "...да как вы можете такое говорить, у нас самые лучшие телефоны в мире, они не могут барахлить, вы наверное неправильно их эксплуатируете и у вас некондиционированные помещениия"...
В общем, поматерились мы и по радиолюбительской технологии нарисовали платки на стеклотестолите, протравили их, перепаяли и с тех пор забыли о проблемах.
Это я к тому, что может у нас помещения недостаточно кондиционированные для правильной работы БЭСТа? Судя по молчанию И-С он слышать о такой проблеме не хочет...
Проблема скорее в том что база БЕСТ-4
1, написана по старинке
практически нет уникальных ключей
2,нет триггеров и транзакций
Отсюда всякие сбои и т.д.
Думаю проблема в кэшировании записи, ключи уникльные есть, но сидят они в кэше, на диск не записаны, когда готовится следующая запись берется следующий по порядку номер, а он еще не изменился, вот и образуются перехлесты.
Т.е. операционка неправильно работает с кэшем, он живет сам посебе.
Отменить кэш на запись - снизить производительность.
Отсюда вопрос, какая дисковая подсистема, IDE RAID на матери или нормальный сказевый RAID контроллер? А какя операционка? Включено ли кэширование записи?
А вообще то встречалась ситуация, когда отчеты и данные показывались неправильно, хотя только что все было хорошо.
После сноса временных файлов на локале все приходило в норму.
технология обработки - это уже к ИС.
У сантехника была когдато проблема блокировки записи не помню чем закончилась, может ИС изменил приципы блокирования файла ключей для обеспечения работы большого количества юзеров, вот и полезли другие проблемы, но это так - домыслы, рассуждения о том, что неизвестно. А о транзакциях речь, наверно, идти не может в их обычном понимании, скорее можно говорить о создании временных файлов, которые и имитируют транзакции как таковые.
Однажды пришлось прибегнуть к следующему фокусу, проставить просто редактором номер ключа на полтора десятка больше и создать записи с пропущенными номерами, зачем мудрил забыл, но все прошло нормально на рабочей базе, в процессе работы пользователей.
Joined: 17 Mar 2003 Posts: 357 Location: Гусев Сергей Александрович Occupation: Сисадм Interests: Нижний Новгород
Posted: 20 Feb 2004 15:20 Post subject:
Quote:
Отсюда вопрос, какая дисковая подсистема, IDE RAID на матери или нормальный сказевый RAID контроллер? А какя операционка? Включено ли кэширование записи?
Было это и на W2KS и на Самбе. В одном случае SCSI RAID без кэширования записи, в другом чистая IDE. Но вряд ли это связано именно с кэшированием - вообще, любая нормальная операционная система прежде чем открыть запись с диска, пытается найти ее в кэше, причем и в кэше записи и в кэше чтения. В противном случае получится полная лабуда, т.к. при интенсивной работе с диском юзера начнут цеплять не те данные со всеми вытекающими...
именно с кэшированием - вообще, любая нормальная операционная система прежде чем открыть запись с диска, пытается найти ее в кэше, причем и в кэше записи и в кэше чтения. В противном случае получится полная лабуда, т.к. при интенсивной работе с диском юзера начнут цеплять не те данные со всеми вытекающими...
Ну вроде и получается лабуда, при интенсивной работе.Хотя правда Ваша, если просто проблема с кэшем, то было бы хуже. Значит подобное предположение не проходит.А что остается? Грешить на сеть? Ну это, наверно, совсем выборочно, жалоб многовато.
Тогда к механизму уникальности ключей в БЭСТе.Можно порассуждать, что правильнее будет: открывается на запись ннопер, читается, увеличивается на единицу, записывается, далее работается с памятью. Если отмены документа нет, то записывается, если отмена, то можно получить пропуск номера в ннопер.Здесь пересечся можно только, если ошибка в программе, но это уже у всех. Другой вариант работы с ннопер в голову не приходит, только если наоборот- сначала работаем с временным документом, а при записи документа записывается и ннопер и в документ и в ннопер. Но это, как-то не очень складно. Может я и не прав.
Проблема стабильно возникает на W2KS. А у кого нибудь было на Netwar'и ?
Не было у меня такого на Нетвари 4.1. А собираюсь переходить на W2К.... Так что мне к этому готовиться или как-то что можно в настройках сделать?
У нас, тоже 3 года, после перестройки сети, пришел и ужаснулся, но тогда чего только не было , подобных вещей не наблюдается, но кто знает, может скрывают
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
.gif)
Так что мне к этому готовиться или как-то что можно в настройках сделать?
, подобных вещей не наблюдается, но кто знает, может скрывают 
