Переодически вылетает выгрузка в Excel

[gl00mie]

Единственная, может, особенность (или это мне так повезло): объект Thread должен по возможности явно создаваться на клиенте, например, через classFactory::makeObjectOnClient()

[sukhanchik]

Цитата:

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

Единственная, может, особенность (или это мне так повезло): объект Thread должен по возможности явно создаваться на клиенте, например, через classFactory::makeObjectOnClient()

Может это связано с тем, что класс COMExcelDocument_RU клиентский?
Я действительно создавал объект Thread на клиенте, ибо там же создавал экземпляр COMExcelDocument_RU (или Word).

Но у меня была реализована более сложная схема. Фактически, я продублировал (неполностью конечно) классы COMExcel/WordDocument_RU. Т.е. создал класс, у которого сделал параметр - требуется ли запускать код в потоке или нет. Для Word запуск в потоке обязателен, а для Excel - нет (ибо можно сделать через .NET). Но можно и Excel запустить в потоке - ограничений нет.

А дальше - этот класс-обертка запускает начальный метод, строящий отчет. Собственно - все. Все расчеты при желании - всегда можно сделать и на сервере.

[gl00mie]

Цитата:

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

Может это связано с тем, что класс COMExcelDocument_RU клиентский?

У меня в ходе экспериментов вообще не получилось запустить дополнительный поток на сервере - даже с простеньким тестовым статическим серверным методом, не то что с каким-то рабочим кодом Что характерно, при реализации класса TutorialThread, похоже, эти попытки тоже остались безуспешными.

Цитата:

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

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

Вот чем мне не нравятся классы ComExcel/WordDocument_RU - это что они везде в коде создаются через new(), а не через статический construct(), как следствие, просто так подменить штатный класс таким вот, к примеру, наследником, реализующим работу в отдельном потоке, уже не получится - придется править все места, в которых создаются экземпляры этих классов, что не совсем вписывается в эту формулировку:

Цитата:

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

Эта проблема одноразовая - один раз сделал, а потом забыл.

С SysExcel* в этом плане куда проще, потому что классы написаны "прямее", и достаточно заложить нужную логику принятия решения о том, как работать с Excel (через COM или .NET) в одно-единственное место - SysExcelApplication::construct(). Хотя предварительно, разумеется, нужно вычистить в коде "нарушения абстракции" - работу напрямую с COM-объектами, обертками для которых выступают классы в приложении Аксапты.

[BOAL]

Цитата:

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

Вот чем мне не нравятся классы ComExcel/WordDocument_RU - это что они везде в коде создаются через new(), а не через статический construct(), как следствие, просто так подменить штатный класс таким вот, к примеру, наследником, реализующим работу в отдельном потоке, уже не получится - придется править все места, в которых создаются экземпляры этих классов,

Ну, автоматизацию и тут никто не отменял.
Делается проект с нужным набором классов-отчктов.
Выгружается в ХРО
Заменой текста по заменяемым названиям
Загрузка ХРО
Проверка компилом - правки.

Мы так 60 классов оптом меняли, иначе, конечно, озвереть

[gl00mie]

Цитата:

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

Ну, автоматизацию и тут никто не отменял. Делается проект с нужным набором классов-отчктов. Выгружается в ХРО Заменой текста по заменяемым названиям

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

1. в любой момент может появиться код, написанный коллегой-программистом, забывшим про эти исправления, либо локализаторами в очередном hotfix rollup'е, который будет использовать старый класс - и эти дыры надо будет условно постоянно латать.
2. когда меняешь что-то в хрендцати местах (а на ComExcelDocument_RU.new() в моем случае есть 82 перекрестных ссылки ниже usr-слоя), то на usr-слой поднимается фигова туча объектов приложения, которые потом приходится поддерживать: обновлять при переходе на очередной hotfix rollup/service pack, учитывать при накатывании отдельных hotfix'ов, etc. Причем подниматься могут не только методы классов, но и целые формы, например, LedgerRRGEHistoryCompare_W. Это очень удорожает сопровождение приложения

[sukhanchik]

Цитата:

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

Фигня в том, что это нельзя назвать решением "сделал один раз и забыл", потому что

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

В контексте данного обсуждения - я хотел сказать - что сделав класс-обертку, описав механизм его использования и следя за тем, что его используют правильно - можно в рамках отчетов, использующих этот класс-обертку забыть про способ обхода падений Word/Excel (поток, .NET и т.д.). Собсно - это один из принципов ООП - инкапсуляция.

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

[AndyD]

Цитата:

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

У меня в ходе экспериментов вообще не получилось запустить дополнительный поток на сервере - даже с простеньким тестовым статическим серверным методом, не то что с каким-то рабочим кодом Что характерно, при реализации класса TutorialThread, похоже, эти попытки тоже остались безуспешными.

Для этого классом AOSLoadGen можно воспользоваться.