Аксапта выдает AsciiIo объект не инициализирован?

[Hidden]

Пакетно каждый час запускается преобразование текстовых файлов, и иногда по непонятным причинам выдает что "AsciiIo объект не инициализирован'. Это здорово мешает, так как процедура не выполнена и плюс все пакетные задания виснут в ожидании. В чем может быть причина и как обойти проблему или разрешить?

Цитата:

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

Пакетно каждый час запускается преобразование текстовых файлов, и иногда по непонятным причинам выдает что "AsciiIo объект не инициализирован'. Это здорово мешает, так как процедура не выполнена и плюс все пакетные задания виснут в ожидании. В чем может быть причина и как обойти проблему или разрешить?

Может что-то работает с файлом помимо Ax в этот момент?

[Logger]

Цитата:

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

Пакетно каждый час запускается преобразование текстовых файлов, и иногда по непонятным причинам выдает что "AsciiIo объект не инициализирован'. Это здорово мешает, так как процедура не выполнена и плюс все пакетные задания виснут в ожидании. В чем может быть причина и как обойти проблему или разрешить?

Скорее всего в момент инициализации объекта возникает ошибка.
1. Либо некорректный путь передан. - Тогда проверять его на корректность. WinApi ::fileExists()
2. Либо файл уже существует и переписать его поверх невозможно, так как он, например, открыт другим приложением на запись.
3. Может быть есть какие то ограничения в операционке на число открытых файлов. Учтите что файл после отработки кода может быть закрыт не сразу - из-за того что сборщик мусора не сразу убивает объект. Может быть тогда для файла AsciiIo принудительно вызывать Finalize() ?

[Hidden]

Цитата:

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

Скорее всего в момент инициализации объекта возникает ошибка.
1. Либо некорректный путь передан. - Тогда проверять его на корректность. WinApi ::fileExists()
2. Либо файл уже существует и переписать его поверх невозможно, так как он, например, открыт другим приложением на запись.
3. Может быть есть какие то ограничения в операционке на число открытых файлов. Учтите что файл после отработки кода может быть закрыт не сразу - из-за того что сборщик мусора не сразу убивает объект. Может быть тогда для файла AsciiIo принудительно вызывать Finalize() ?

Поробовал file2.finalize();
ТОгда пишет Метод объявлен как protected и может вызываться только из методов классов-наследников AsciiIo.

[kashperuk]

Можно создать класс наследник AsciiIO и использовать его вместо базового. А в нем перекрыть метод finalize() и уровень доступа сделать ему public

[Recoilme]

Есть ещё "железячная" проблема, когда файлы "зацепляются" операционкой. Типа файл используется, хотя он на самом деле не используется. Это наблюдается у нас когда за день создаются/удаляются по несколько тысяч файлов. NTFS. Лечим периодической чисткой и дефрагментацией.

[Logger]

Цитата:

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

Можно создать класс наследник AsciiIO и использовать его вместо базового. А в нем перекрыть метод finalize() и уровень доступа сделать ему public

а еще можно объявить переменную типа Object присвоить ей наш файл и вызвать для Object метод Finalize()

Проверка на Protected Private происходит только на этапе компиляции и легко обходится при работе. Хотя это окнечно методологически неверно и правильнее делать через наследование как kashperuk указал.

[belugin]

WinApi ::fileExists() говорит, что занятые файлы не существуют, более корректная версия аfileExists2

Вместо finalize можно попробовать использовать io=null (хотя неизвестно точно когда его выкинет сборщик мусора, но на практике это прокатывало)

[Hidden]

Всем спасибо! Попробую! Самое странное вылетает с такой ошибкой где то 1 раз из 50 запусков, т.е. 1 раз в два три дня.

[Sasha]

Можно еще добавить проверку инициализации объекта файла с выброской исключения, а в catch алгоритм перехода к следующему файлу (продолжения обработки далее).... и тогда пакетник останавливаться не будет, а при следующем запуске снова займется проблемными файлами...