Это просто ЖЕСТЬ :-))))

Кстати про кеширование таблиц идея хорошая...
Проверяю...

Если есть дока про назначения пропертей и нафига нужны... был бы признателен..
Ибо доков по этой теме просто нет ..

Выключение индексов не помогло, они тупо прибиты к коду.. Стоило их выключить, документы вообще перестали проводится.

и в некоторых таблицах.... проперти Clusterindex указано, но индекс на MS SQL нифига не кластерный...

Так же указано пропетри - праймарикей в табличке в репозитарии..
а на MS SQL ключа даже близко нет
Это нормально?

Еще раз повторюсь.. Что досталось в наследство, то и сопровождаем...
Максимум - настройки на MSSQL

miklenewiscrafm
уроков логики не видно. Обсуждение недостатков Аксапты, ничего лишнего и личного.
Странно, что не видите.
Человек пишет реальные проблемы, а когда предлагают помочь (я про себя).
Пишет

To ALL... Прекращайте пытаться "спасти бедную Volochkov" :-) Топик про недостатки Аксапты..

Спрашиваеться нафига было вообще писать реальные проблемы, на основе их сделать какие-то выводы, тему превратить в я не я, корова не моя.
Чтоб потом всё подитожить таким макаром.
Просто мотивации не пойму неужели выплеснуть эмоции важнее, чем найти решение.
Те вопросы которые поднял человек, сложно просто с бухты барахты решить.
Сначала надо не один час потыкаться и перепроверить элементарные ошибки, которые могли быть допущены. Просто кричать Мы все погибнем бесполезно.
Надо сесть и включить мозг. Искать и не сдаваться.

На предыдущей странице, я Вам уже ответил.
Топик про проблемы в Аксапте.. Их описал, с чем можно столкнуться, если программа продается по принципу, это круто.. а не это надо..

Привел пример как это у меня.. И тут же все поехали спасать :-)

CoolibinVolochkovaTo ALL... Прекращайте пытаться "спасти бедную Volochkov" :-) Топик про недостатки Аксапты..
Если надо будет, я задам вопросы на Аксфоруме.

Volochkova, я Вам сочувствую. Неужели не понятно, что не слезут они с Вас с живого))). Когда аргументов полноценных нет, то конечно же рулит переход на личности. Все это отлично уже отшлифовано у Ваших оппонентов на Аксфоруме. Топик уже давно больше обсуждает недостатки не Аксапты, а Ваши.

Но Вы сами нарвались. Мне, все-таки, кажется, что в принципе неверно оценивать такую систему, как Аксапта с точки зрения технологической. Как будто бы основное ее предназначение в создании оптимальных запросов и блокировок. Я думаю, что это не так. Все-таки предназначение системы несколько в другом, в возможности получения максимально возможной в каждой конкретной ситуации эффективности бизнес процессов. Именно с этой точки зрения прежде всего и имеет смысл оценивать как достоинства, так и недостатки системы. И в данном контексте утверждение, что самописка однозначно лучше серийной системы потому что там "лучше запросы" выглядит не очень убедительно. Связь очень косвенная. Вот если бы Вы рассказали, как Аксапта мешает предприятию зарабатывать больше денег, то это было бы намного объективнее. И автору топика, конечно же, было бы легче убеждать влядельцев бизнеса в неких преимуществах собственной разработки. Не, ну он, конечно же, может им рассказать про какие-то там блокировки и "ректальные кубы", но вряд ли это будет то, что они от него хотят услышать.

Конечно нарвались.. :-)
Мне понравилось что в ходе темы "убить Волочкову" пара реальных точек, через которые можно провести прямую, все таки появились..
И именно это необходимо, для принятия решения что делать со зверьем - Аксапта..

И в очередной раз скажу респект muzzy за его проект по Аксапте...
Так же все кто откликнулся на тему.

Coolibin Когда аргументов полноценных нет, то конечно же рулит переход на личности. Все это отлично уже отшлифовано у Ваших оппонентов на Аксфоруме. Топик уже давно больше обсуждает недостатки не Аксапты, а Ваши.


Кстати, вот этого не было...
В корне...

1. я не дал полной описания проблемы.. Т.к. и опять 25.. не собирался решать свою проблему.. в этой ветке. Эта ветка про иное :-)))
2. обсуждение к технологии так и не перешли.. но некоторые моменты были озвучены..
3. Я знаю базу с точки зрения MS SQL люди с точки зрения Аксапты... ясен пень что сложно найти общий знаменатель..

mazzyVolochkova
Если есть дока про назначения пропертей и нафига нужны... был бы признателен..
Ибо доков по этой теме просто нет ..
Пля... Я же ссылку давал здесь.
Хорошо, еще раз: Аксапта на msdn: http://msdn.microsoft.com/ru-ru/dynamics/ax/default(en-us).aspx
кроме того, у вас в Аксапте в меню Помощь есть пункт Руководство разработчика.

про проперти здесь http://msdn.microsoft.com/en-us/library/aa871620.aspx

Volochkova
Выключение индексов не помогло, они тупо прибиты к коду..

Такого не бывает. Разбирайтесь и пилите дальше.

Volochkova
Так же указано пропетри - праймарикей в табличке в репозитарии..
а на MS SQL ключа даже близко нет
Это нормально?

Нет. Разбирайтесь. Ключевое слово - Синхронизация.

Ну ты совсем меня за приму держишь :-)))
Синхронизация.. сделает чтобы проперти были равны структуре на сервере :-))
А у меня сейчас идут расхождения... Почему так случилось.. вопрос пятый...
Но это нормальная? обычная ситуация?
И как например проверить по 1900 объектам, что структура совпадает с тем что на MS SQL?



автор
Volochkova
Выключение индексов не помогло, они тупо прибиты к коду..

Такого не бывает. Разбирайтесь и пилите дальше.


Знаю, что крокодилы не летают... Но реально вылетела у всех ошибка, не обнаружен индекс, которому выключили енабля...



http://msdn.microsoft.com/en-us/library/aa871620.aspx
Это чисто текст.. Что такое кластер индекс, я типа догадался...
и праймари кей тоже..
А на что оно влияет и нафига надо?



автор CacheLookup - Determines how to cache the records retrieved during a lookup operation.

Ну и как это понимать?
Вот больше всего мне нравится 97 аксес , хоть и вешал проц в 100% но зато дока по нему как для дебилов.. все ясно... куда, сколько.. от куда и зачем...

дока же с 2000-го... стала, вода водой.. нифига не ясно... зато проц не лочится :-)))

P.S. Только не надо ПРО ДОСТОИНСТВА И УЩЕРБНОСТЬ АСКЕСА НАЧИНАТЬ!!!!!!! :-)

beluginiscrafmbeluginСейчас я отвечаю на вопрос "зачем блокировки при обработке прихода".
так может наконец-то ответите.

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

Утверждение 1. Цитата (см выше)
Транзакция всегда вызывает монопольную блокировку любых данных, которые она изменяет , и держит блокировку до тех пор, пока транзакция не завершится, независимо от уровня изоляции, установленного для транзакции.

Утверждение 2: Увеличение складских остатков является обновлением данных

=>

Увеличение складских остатков блокирует изменяемые остатки до конца транзакции.

теперь "зачем"

SQL сервер - блокировочник,

это значит, что изоляция транзакций осуществляется при помощи блокировок.

Например, у нас есть запрос

Когда выполняется этот запрос SQL сервер обновляет записи остатков. В данном случае пусть будет две записи.

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

Для этого SQL сервер ведет протокол, чтобы в случае ошибки откатить транзакцию. При ошибке он пройдется по протоколу и вернет даные на место.

Допустим, SQL успел обновить одну из записей ('гайки'), а при обновлении другой возникла ошибка.

Транзакция откатывается и данные возвращаются на место.

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

Для этого используется блокировка.

Таким образом при увеличении остатка тоже необходимо блокировать изменяемые записи.

P.S. В Ax2009 обновление остатков делается одним простым SQL запросом на транзакцию непосредственно перед коммитом (если интересно могу привести кусочки исходников, в общем виде описано в статье Дениса Федотенко, ссылку на которую я приводил).

Вопросы:
1. Я ответил?
2. Вы согласны ли вы с такой картиной, если не согласны в чем здесь ошибка?

Баба яга против!!!! :-)))
ИМХО изначально кривая логика.
И пусть меня опять закидают камнями, но привожу уже не первые факты...

1. Первичен АЛГОРИТМ! а уже потом код...
И так... Процедура прихода...
Все что было описано с примером про приход и перемещение.. это все лажа...
В жизни ( мое имхо) должно быть так...

Берем накладную.... проверяем все ее признаки... +/-.. кто проверил, заполнены ли сроки годности и т.д.
А уж потом проводим по регистрам партий и в самом конце... Если нет партий, то регистр остатков.
И никакие блокировки не нужны. В самом примере нарушена сама логика прихода.

2. Теперь сам код...
Обработается на 1000 порядков быстрее чем цикл на клиенте или АОСе...
И не надо никаких костылей из темы кеширования таблиц на АОСе...
MS SQL все сделает сам...

Update сделается (одновременно для всех записей).
Теперь про блокировки...
На момент выполнения транзакции, а это уж точно толика времени для документа в 1000 строк .
Записи с товаром будут заблокированы. Если нужен код MS SQL я его приведу..
И сканирование таблицы
А ля Аксапта

отдаст только те записи которые доступны и не заблокированы ТРАНЗАКЦИЯМИ!
Которые сделает один сервер MS SQL.
И в результате для продажи нельзя будет выбрать то, что сейчас заблокировано приходом.

Что мы имеем в сухом остатке?
Никаких гонений данных по сети, ни какого геморроя, простой доступный T-SQL.
Но этого движек Аксапты делать не умеет.

Мой же вариант


не споткнется об блокировки...
Т.к. у команды есть такая фишка - ExecTimeOut в результате... запрос на просмотр остатков подождет прихода всей партии 1000 СТРОК!!!! и тут же покажет их...

В варианте Аксапты.. будет While Select на приходе с блокировками или кешированием... на приходе и на просмотре остатков..