Страница 1 из 1

Обращение к некорректному дескриптору

Добавлено: 16 окт 2009, 19:10
maikl
8.10 (MS SQL) Установил все обновления по 12 октября.
Если у пользователя ест огранивение в протекте на таблицу (PLPOR для группы дескритпоров, то вопытке войти в приходные ордера вылетает с сообщением Обращение к некорректному дескриптору.
Не пойму где копать.

Добавлено: 16 окт 2009, 21:55
Алексей
в ордера?

Добавлено: 16 окт 2009, 22:32
m0p3e
В 22 атлантисе бага при использовании фильтров по группам записей. В 23 исправили.

Добавлено: 17 окт 2009, 10:46
maikl
Опять выходит установка новых обновлений это лотерея. Установил обновления от 14-16 октября, проблема решилась. Как это достало.
Надо бы на форуме сделать отдельную ветку, где по платформам пользователи бы писали об установленных и проверенных обновлениях.
Интересно как бы мы работали если бы не вышли новые от 14-16 числа обновления?. Назад откатывались бы?
Люди как вы поступаете когда обнаруживаются существенные ошибки, а уже все установлено и работает в реальном режиме?

Добавлено: 17 окт 2009, 11:53
m0p3e
maikl
Ну вам еще повезло. :)
Мы накатили 22 атлантис на тестовую. Проверили что все работает (под своим админским аккаунтом). Доступ по группам записей только у пользователей. С вечера обновили рабочую. А с утра... началось...
Сначала пытались разобраться в чем проблема. По горячей линии с Галактикой запускали разные проверки. После того как одна из проверок убила нахрен все нарезанные меню - откатили базу и exe. Половина рабочего дня - коту под хвост.
Теперь будем еще и под пользователями обновления проверять.

Добавлено: 17 окт 2009, 17:04
KATZ
maikl писал(а):Опять выходит установка новых обновлений это лотерея... Как это достало.
Точно, лотерея. Причем самая безвыигрышная среди всех известных лотерей. Каждый месяц - десятки заплат и сотни (а то и тысячи) новых ошибок. А корпорация знай продолжает себя нахваливать. Вот из недавнего: Модуль AQA: высокое качество и надежность системы "Галактика ERP".
maikl писал(а):Люди как вы поступаете когда обнаруживаются существенные ошибки, а уже все установлено и работает в реальном режиме?
Сначала долго плюемся и материм разработчиков, а дальше - по конкретной ситуации. Если можно придумать какой-то вариант работы с обходом ошибки - используем его, если нет - откат.
m0p3e писал(а):Мы накатили 22 атлантис на тестовую. Проверили что все работает.
Мы бы рады проверить, да слишком много всего используется, полноценную проверку при всём желании не организовать. Можно, конечно, выборочно ткнуться в 2-3 места, но толку от этого 0.

Добавлено: 17 окт 2009, 18:05
galover
+1. работает стабильно, только то, что сами написали. Если потоковая форма, то берем NRec и тянем все поля самостоятельно. По причинам частых ошибок и исправлений вообще отказались от некоторого функционала - например от автоматического расчета графиков в ремонтах

Добавлено: 17 окт 2009, 20:09
ilshat
В подразделение тестировщиков опять набрали новую партию студентов тока что из институтов видать :) Каждый "накат" лотерея со стопроцентным выпадением чего-нибудь. :( Грустно

Добавлено: 18 окт 2009, 11:40
maikl
Пора создавать инициативную группу (на платной основе), что бы писать возмущенные коллективные письма к руководству Галактики.

Добавлено: 19 окт 2009, 10:51
galover
это не поможет, руководство в курсе что такой бардак. только ничего менять не будут - зачем? бабло то капает

Добавлено: 19 окт 2009, 13:13
Seybukan
бабло то капает
На "игле" все торчим. :grin:

Добавлено: 19 окт 2009, 13:23
Seybukan
Теоретически:

Всю работу системы можно разбить на несколько здоровенных кусков.
1. Логистика.
2. Планирование производства.
3. Бухучет.
4. ЗПЛ.
5. Финансы.

Для чего нужны обновления? В 90% случаев - обновление законодательства. Законодательство влияет в процентах:
1. Логистика. 5% Печатные формы.
2. Планирование производства. 0%
3. Бухучет. 30%
4. ЗПЛ. 60%
5. Финансы.0%

Печатные формы в состояние написать почти все.
Бухучет в Галактике самодостаточный. По крайней мере есть ТХО API. Теоретические правила бухучета не изменятся еще лет 100!!!

Получается что изменение законодательства в основном направлено на модуль ЗПЛ. - все возможные отчеты, хитрые расчеты начисление и прочее прочее.
Малая зависимость всей системы от учета персонала позволяет выделить данный блок в отдельную систему, на которую будут накатываться обновления, все остальное в отдельную БД.

Делаем выводы.

Добавлено: 19 окт 2009, 13:59
maikl
В свое время компонентная система преподносилась как, если вас устраивает работа данной компоненты, скажет сбыт, то ее можно не обновлять, а обновлять то, что надо.
В реалиях оказалось все совсем не так. Я даже не пойму зачем ставить обновления и мучиться, надо просто брать новый дистрибутив, т.к все компоненты неразрывывно связаны.

Добавлено: 19 окт 2009, 17:44
Алексей
я тоже мечтал, когда переходили на компонетную версию что... раз и вот оно, счастье. нашел рабочую компоненту, и не меняешь её, ан-нет...
я тут пытался обновить одну компоненту - она потянула за собой другие и в результате обновил 70% ехе каталога...
ну и нафиг такая компонентность если один фиг надо качать весь ЕХЕ .

Добавлено: 19 окт 2009, 17:58
galover
компонентность работала бы нормально, если бы все было на интерфейсах (как в COM), без прямого вызова. Поскольку в таком случае (в случае прямого доступа) идет проверка на контрольную сумму.
т.е. вот так бы работало нормально:

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

objInterface IComp1;
   procedure SomeFunc;
end;

vipInterface Comp1 inherits IComp1;

// Comp2 не привязан к реализации Comp1 (и можно использовать разные версии Сomp1, если не менялся интерфейс IComp1)
Interface Сomp2;
   var _comp1 : IComp1;
   LoadVipRef(_comp1, 'Comp1');
   
   _comp1.SomeFunc();    
end.
а так уже нет:

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

objInterface IComp1;
   procedure SomeFunc;
end;

vipInterface Comp1 inherits IComp1;

// Comp2 привязан к реализации Comp1 (идет прямой вызов), при вызове происходит сравнение контрольных сумм
Interface Сomp2;
   var _comp1 : Comp1 new;
   _comp1.SomeFunc();    
end.