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

[raniel]

Добрый день. Столкнулся с интересной проблемой. Есть выгрузка отчёта в Excel. Есть 2 AOS-а на одном этот очёт выходит без проблем чтобы мы не делали. На втором же периодический, вылетает. Например когда мы сворачиваем все окна(во время формирования отчёта в фоновом режиме) или разворачиваем(хотя как это может влиять???).Либо когда мы что нить копируем в буфер во время выгрузки. И ошибки типа "Метод Insert в COM-объекте классавозвратилкод ошибки....". Разница межу Приложениями лишь в лицензиях...на одном которое нормально работает и ни в какую не вылетает стоит лицензия на разработку. Во втором приложении разработки нет. Запускаю на третьем приложении тоже где отсутствует лицензия на разработку и приложение также вылетает. Странно как это может влиять на стабильность? И как сворачивание всех окон или разворачивание может влиять на работу AX-Excel(к томуже когда Excel в фоновом режиме)???
Аксапта 2009-ой версии. Excel любой. Операционка как ХР так и 7-ка.

[ZornFire]

Как я понимаю аксапта у Вас работает просто с машины, т.е. не через терминальный сервер, если да, то попробуйте через него, это самый лёгкий способ решения проблемы. Если нет, отчётом пользуются на одинаковых слоях?
Вы запускаете его на разных машинах под разными аосами? Проверьте версии клиентов на машинах, по хорошему они должны быть одинаковыми с версией на основном сервере.

[Владимир Максимов]

1. Какой способ выгрузки в Excel используется? Поячеечная вставка, буфер обмена, ADO RecordSet?
2. Работа ведется в терминальной сессии?

[gl00mie]

Цитата:

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

И как сворачивание всех окон или разворачивание может влиять на работу AX-Excel (к томуже когда Excel в фоновом режиме)???
Аксапта 2009-ой версии.

У-у-у, сворачивание окон в 2009-й при работе с Excel через COM наинепосредственнейшим образом влияет на стабильность работы с Excel! Это смех сквозь слезы... см.
Ошибка времени выполнения в ComExcelDocument_RU.findRange()
Ошибка чтения файлов XLS под Windows 7 - тут предложено решение: переписать взаимодействие с Excel на использование .NET вместо COM. К слову, тут вот предлагают запускать клиента на терминальном сервере, так я по своему скромному опыту скажу, что это лишь усугубит ситуацию, потому что на настольном компе у вас несколько десятков процессов и 300-800 потоков, и все вылетает из-за этих <censored> таймаутов, а на терминальном сервере будет несколько сотен процессов и эдак под 4-5 тысяч потоков, так что вылетать будет куда чаще.

Цитата:

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

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

[Serg]

2 gl00mie

Можете поподробней рассказать, что значить переписать на .NET ?

Проблема взаимодействия Axapta c com-объектами под Windows7 и Winserver 2008 общеизвестна и на сколько я знаю в Microsofte пытаются ее решить, но как то не очень удачно (заплатки с периодическим обращением к объектами и т.д.)

[gl00mie]

Цитата:

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

Можете поподробней рассказать, что значить переписать на .NET?

Взять классы-обертки для работы с Excel и переделать их как-то так (на примере SysExcelCells):

public static client SysExcelCells construct(MSOfficeVersion _version, COM _cells, Microsoft.Office.Interop.Excel.Range _cells_net = null)
{
    if (_cells_net)
    {
        return SysExcelCells_NET::construct( _version, _cells_net );
    }
    return new SysExcelCells(_cells, _version);
}
///////////////////////////////////////////////////////////////////////////////
// реализация обертки для работы с Excel через Microsoft.Office.Interop.Excel
class   SysExcelCells_NET
extends SysExcelCells
{
    Microsoft.Office.Interop.Excel.Range    cells_net;
}
// возвращает ClrObject из пространства имен Microsoft.Office.Interop.Excel, оберткой для которого является экземпляр класса
// это часть внутренней инфраструктуры семейства классов SysExcel*, реализующих работу через .NET
protected CLRObject clrObject()
{
    return cells_net;
}
public final COM comObject()
{
    // copy-paste кода метода-обработчика comObject(), общего для классов SysExcel*, реализующих работу через .NET
    str   methodName = strfmt( '%1.%2', classid2name( classidget( this ) ), methodstr(SysExcel, comObject) );
    throw error( strfmt( "@SYS75628", methodName, "@SYS95798" ) );
}
// способ, которым класс взаимодействует с Excel
// это часть внутренней инфраструктуры семейства классов SysExcel* для реализации кое-каких проверок
protected final InteropKind getXlInteropKind()
{
    return InteropKind::ClrInterop;
}
public SysExcelCell item(int _row, int _column)
{
    // предполагаем, что класс может работать и на сервере, при этом вызывающий код не должен знать детали взаимодействия с Excel
    new InteropPermission( InteropKind::ClrInterop ).assert();
    // BP deviation documented
    return SysExcelCell::construct( version, null, cells_net.get_Item( _row, _column ) );
}
protected void new(Microsoft.Office.Interop.Excel.Range _cells_net, MSOfficeVersion _version)
{
    super( null, _version );
    cells_net = _cells_net;
}
public SysExcelRange range(str _range = '')
{
    SysExcelRange   ret;
    ;
    if (_range != '')
    {
        new InteropPermission( InteropKind::ClrInterop ).assert();
        // BP deviation documented
        ret = SysExcelRange::construct( version, null, cells_net.get_Range( _range, this.getClrMissingArg() ) );
    }
    else
    {
        ret = SysExcelRange::construct( version, null, cells_net );
    }
    return ret;
}
public static SysExcelCells_NET construct(MSOfficeVersion _version, Microsoft.Office.Interop.Excel.Range _cells_net)
{
    return new SysExcelCells_NET( _cells_net, _version );
}

Соотв., аналогично переписываем остальные классы, в SysExcelApplication::construct() реализуем возможность создания экземпляра класса-наследника, работающего через .NET, вычищаем весь код, дергающий SysExcel.comObject() - и готово

[BOAL]

Да уж, тема грустная для АХ2009, на АХ4 не было таких явных проблем при шевелении мышкой или кликом на запуск другой проги в момент построения Ехель отчетов.
Мы переписали на .НЕТ проблема снялась, но возникла несовместимость с разными офисами на клиентских местах - решение обсуждалось в какой-то теме, нужно ДЛЛ от офиса 2007 засунуть в БИН на клиенте, тогда на Офис2003 заработает.

А тут начала сбоить даже стандартная выгрузка формы (фича АХ2009) в Ехель по кнопочке на форме или Ctrl-E
Она ж тоже СОМ и ее наш перепис не коснулся.... и чинят это в МС, судя по году возникновения темы, давно... точнее вообще не чинят, тк потуги try-catch 4 раза - это бутафория, пробовали, фигня-с

Вторая панацея помимо .НЕТ, это запуск в потоках (для Ворда решили именно так, так на .Нет он не пошел, лезли неисправимые баги).
С потоками все ок, там никто мышкой не пошевелит и не поломает хрупкую конструкцию СОМ вызова.
Минус - проблемы с выводом инфолога, тк строится все это "где-то там".

[gl00mie]

Цитата:

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

Минус - проблемы с выводом инфолога, тк строится все это "где-то там".

Вроде в отдельном потоке можно "вырезать" выведенные в нем сообщения через infolog.cut(), вернуть его через Thread.setErrorLog(), и потом вывести это все в основном потоке через infolog.view(). По-моему, куда больше проблем в случае отдельного потока с созданием "обертки" для запуска куска функционала в отдельном потоке, передачи нужных ему данных, etc...

[sukhanchik]

Цитата:

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

Минус - проблемы с выводом инфолога, тк строится все это "где-то там".

Это скажем так - не проблема. Это особенность, про которую не нужно забывать и выводить надо через Thread.setoutputParm()

Цитата:

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

По-моему, куда больше проблем в случае отдельного потока с созданием "обертки" для запуска куска функционала в отдельном потоке, передачи нужных ему данных, etc...

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

[raniel]

Ну да. Выполняется всё на локальной машине(не терминалка). Приложение одно и тоже, просто на 2 стоят лицензии без разработки, а на одном(на котором всё ок.) с разработкой. Вот вся разница. Слои работы идентичны. Выгрузка идёт поячеечно через COM-объекты.
Самое интересное, что это работает на приложении с лицензией на разработку!

[AndyD]

Делайте не прямые вызовы методов com-объектов, а через обертку ComDispFunction - получите значительно более стабильную работу

[raniel]

sukhanchik а можно поподробнее, либо ссылку на пример?
Спасибо!

[sukhanchik]

Цитата:

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

sukhanchik а можно поподробнее, либо ссылку на пример?
Спасибо!

А поподробнее о чем?

[raniel]

Цитата:

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

А поподробнее о чем?

Как в потоке запустит в потоке выгрузку в Excel?

[sukhanchik]

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

Или Вы столкнулись с тем, что импорт работает, а экспорт как раз-таки нет? Было бы весьма странно

[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. Это очень удорожает сопровождение приложения