Ошибка времени выполнения в ComExcelDocument_RU.findRange()

[AndreyStar]

Тоже столкнулись с этой проблемой, идея сделать как в российском функционале, с макросами на try catch очень не понравилась, да и объем переписывания немалый

Проблема возникала только на системах с Win7, XP + Office 2010 + dax 2009 работало без проблем

Когда искал причину, увидел что в других языках обращения к COM компилируются с атрибутом [STAThread] - однопоточное исполнение, ну и появилась мысль что многопоточность Win7 мешает жить. Попытка запустить dax2009 в режиме совместимости чуть улучшила ситуацию, но проблему не решила и тогда пришла идея запустить класс экспорта в отдельном потоке, и все заработало

Сейчас все протестировано в разных связках, в том числе и в 64-битной системе, все работает, и переписывать нужно только способ запуска класса

[Logger]

Цитата:

Сообщение от AndreyStar

Когда искал причину, увидел что в других языках обращения к COM компилируются с атрибутом [STAThread] - однопоточное исполнение, ну и появилась мысль что многопоточность Win7 мешает жить. Попытка запустить dax2009 в режиме совместимости чуть улучшила ситуацию, но проблему не решила и тогда пришла идея запустить класс экспорта в отдельном потоке, и все заработало

Сейчас все протестировано в разных связках, в том числе и в 64-битной системе, все работает, и переписывать нужно только способ запуска класса

Не могли бы подробнее рассказать что нужно сделать ?

[someOne]

Цитата:

Сообщение от AndreyStar

Тоже столкнулись с этой проблемой, идея сделать как в российском функционале, с макросами на try catch очень не понравилась, да и объем переписывания немалый

Проблема возникала только на системах с Win7, XP + Office 2010 + dax 2009 работало без проблем

Когда искал причину, увидел что в других языках обращения к COM компилируются с атрибутом [STAThread] - однопоточное исполнение, ну и появилась мысль что многопоточность Win7 мешает жить. Попытка запустить dax2009 в режиме совместимости чуть улучшила ситуацию, но проблему не решила и тогда пришла идея запустить класс экспорта в отдельном потоке, и все заработало

Сейчас все протестировано в разных связках, в том числе и в 64-битной системе, все работает, и переписывать нужно только способ запуска класса

Кажется понял как это работает.

Запускаем импорт из екселя, например, так

thread    thread = new thread();

     thread.setInputParm(["Т000081968", "c:\text.xlsx"]); // какие то параметры

     thread.run(classnum(TetImportClass), identifierstr(importFromExcel));

А сам метод импорта в классе TetImportClass

static client void importFromExcel(thread _thread)

ComExcelDocument_RU        document = new ComExcelDocument_RU();
str path;
str parm;
;
[parm, path] = _thread.getInputParm();

    document.open(path, false);

    .....
     ....

Думаю, так импорт не получится прервать передвиганием мыши или переключением окон, так как импорт проходит в отдельном потоке. И ошибок не будет.
Какое никакое, но все же решение.
Только теперь ряд других проблем имеется, например перехват ошибок и вывод их на экран - не тривиальная задача. Но решаемая.

[AndreyStar]

Цитата:

Сообщение от someOne

Только теперь ряд других проблем имеется, например перехват ошибок и вывод их на экран - не тривиальная задача. Но решаемая.

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

все подсмотрено в классе TutorialThread, идея менеджера потоков вспомнилась из проектирования многозадачных систем

все реализуемо

[gl00mie]

Цитата:

Сообщение от AndreyStar

Тоже столкнулись с этой проблемой, идея сделать как в российском функционале, с макросами на try catch очень не понравилась, да и объем переписывания немалый

Если вы про методы класса ComExcelDocument_RU, то, по-моему, это ерунда, другое дело, что это на самом деле не спасает. И еще очень жаль, что для создания экземпляров этого класса не используется статический construct(), нашедший повсеместное распространение в AX 2009

Цитата:

Сообщение от AndreyStar

Проблема возникала только на системах с Win7, XP + Office 2010 + dax 2009 работало без проблем

Попробуйте во время длительного экспорта/импорта попереключаться с окна Аксапты на окна других приложений и обратно или потыкать мышкой в окно Аксапты - все еще "работает без проблем"?

Цитата:

Сообщение от AndreyStar

Когда искал причину, увидел что в других языках обращения к COM компилируются с атрибутом [STAThread] - однопоточное исполнение, ну и появилась мысль что многопоточность Win7 мешает жить.

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

Цитата:

Сообщение от AndreyStar

Сейчас все протестировано в разных связках, в том числе и в 64-битной системе, все работает, и переписывать нужно только способ запуска класса

Попробуйте еще на терминальном сервере с несколькими одновременно работающими сессиями с Аксаптой - причем даже на w2k3 (который ведать не ведает про заморочки W7/W2K8) - узнаете много интересного

Цитата:

Сообщение от AndreyStar

для перехвата ошибок делаем в конце главного метода класса потока, не статического, упаковку инфолога в outParams потока, и дополнительно создан глобальный класс менеджер потоков, в котором все потоки регистрируются и через него можно получить доступ к прогрессу выполнения, инфологу и есть возможность прервать по желанию
все подсмотрено в классе TutorialThread, идея менеджера потоков вспомнилась из проектирования многозадачных систем

"Суха теория, мой друг, но древо жизни зеленеет..." Я лично для себя пришел к выводу, что надо все нафиг переписать на .NET, как рекомендовали тут. Объем модификаций вроде как ощутимый, но хочется реально решить проблему "враз и навсегда", а не шаманить с макросами try/catch. Семейство классов SysExcel* модифицируется на раз, с ComExcelDocument_RU все сложнее из-за того, что его экземпляры создаются напрямую через new(). Пока есть реализация на уровне proof of concept, о результатах тестирования непременно доложусь.

[AndreyStar]

Цитата:

Сообщение от gl00mie

Попробуйте во время длительного экспорта/импорта попереключаться с окна Аксапты на окна других приложений и обратно или потыкать мышкой в окно Аксапты - все еще "работает без проблем"?

тест был жестким, с 4 машин было запущено по 600 потоков параллельно, в задаче запрос InventTrans + InventDim на тестовых данных, при этом активно переключались между аксаптой и все остальным, велся мониторинг нагрузки, все 2400 соединений отработали на 100% успешно
В предыдущих тестах пытались запустить больше 600, и в районе 700 потоков упирались в размер невыгружаемой памяти win, потоки реально не создавались, но в аксапте регистрировались и зависали в выполнении как в клиенте, так и в активных пользователях
А вообще доработка уже ушла на тест к пользователям, время покажет как она ведет себя в жизни

Цитата:

Сообщение от gl00mie

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

На этот вопрос могут ответить только разработчики из Microsoft, но факт что запуск в потоке помогает

[someOne]

Цитата:

Сообщение от gl00mie

Я лично для себя пришел к выводу, что надо все нафиг переписать на .NET, как рекомендовали тут. Объем модификаций вроде как ощутимый, но хочется реально решить проблему "враз и навсегда", а не шаманить с макросами try/catch. Семейство классов SysExcel* модифицируется на раз, с ComExcelDocument_RU все сложнее из-за того, что его экземпляры создаются напрямую через new(). Пока есть реализация на уровне proof of concept, о результатах тестирования непременно доложусь.

Идея с NET - не плохая. Как то сам совсем упустил ее. Попробовал - действительно помогло!!!

Была проблема открытия outlook через COM с вложенным файлом в процедуре обработки счета на оплату. Воспроизводилась лишь на терминальном сервере WinServ 2008 r2. Перевод процедуры на NET проблему решил.

Есть лишь одна проблема такого решения: Не на всех системах, где запускается клиент Аксапты, имеются установленные dll NET компонентов для доступа к office (например Microsoft.Office.Interop.Outlook.dll)

По умолчанию эти компоненты есть лишь на "свежих" ОС типа WinServ 2008, Vista (предполагаю, не проверял). На все другие клиентские места (например XP) придется дополнительно эти компоненты устанавливать и регистрировать - без этого код NET работать не будет. Это дополнительные сложности.

Но тем не менее вариант с NET решения данных проблем мне представляется более "эстетичным"

[gl00mie]

Цитата:

Сообщение от gl00mie

Я лично для себя пришел к выводу, что надо все нафиг переписать на .NET, как рекомендовали тут. Объем модификаций вроде как ощутимый, но хочется реально решить проблему "враз и навсегда", а не шаманить с макросами try/catch. Семейство классов SysExcel* модифицируется на раз, с ComExcelDocument_RU все сложнее из-за того, что его экземпляры создаются напрямую через new(). Пока есть реализация на уровне proof of concept, о результатах тестирования непременно доложусь.

Переписал семейство классов SysExcel на .NET, по ходу дела пришлось добавить несколько новых оберток для интерфейсов Excel, чтобы избавиться от необходимости работать напрямую через COM. Пока повсеместно включать не решился - ограничился лишь стандартным импортом из Excel (класс SysDataExcelCOM) - там тоже понадобилось в несских местах избавиться от прямой работы через COM, но результат превзошел все ожидания! При запуске на терминальном сервере с полусотней параллельно работающих пользовательских сессий импорт из Excel через .NET несмотря на нещадные переключения между окнами (которые раньше валили импорт на раз) не только стабильно завершался без ошибок, но и отрабатывал при этом достаточно шустро - в отличие от "залатанного" импорта через COM, где за счет дополнительных try/catch/retry ошибки вроде как маскировались, но приводили к очень ощутимому замедлению работы.
На очереди - ComExcelDocument_RU, но с ним все сложнее, потому что в отличие от SysExcel* в нем не используется инкапсулированный конструктор, в результате чего подменить класс наследником так вот просто нельзя, и остается либо править кучу мест, где создается его экземпляр, либо нещадно переписывать сам класс...

PS. Тестировалось все на Ms Office 2010.

[belugin]

Цитата:

Сообщение от gl00mie

Переписал семейство классов SysExcel на .NET

Через Office SDK или OOXML SDK?

[AR®]

Вызов ComExcelDocument_RU.findRange(...) падает на всем известном месте

            #StartSafeCall_RU
            comRange = comApplication.range(bookMark);
            #EndSafeCall_RU

если bookMark == "23:66481" или чему-то вроде того, т.е. номер нижней строки больше 2^16. Это лечится?
Версия Excel - 14 (2010).

[Logger]

Цитата:

Сообщение от AndreyStar

Проблема возникала только на системах с Win7, XP + Office 2010 + dax 2009 работало без проблем

Когда искал причину, увидел что в других языках обращения к COM компилируются с атрибутом [STAThread] - однопоточное исполнение, ну и появилась мысль что многопоточность Win7 мешает жить.

Народ решал те же проблемы
https://tips.efmsoft.com/ru/asynchronous-com/
И основные проблемы пошли начиная с Vista.