|
02.08.2011, 12:12 | #1 |
Участник
|
Превышен максимальный размер файла
Здравствуйте уважаемые участники форума, столкнулся со следующей проблемой. При использовании временной таблицы оная в процессе заполняется настолько что файл в который скидываются данные этой временной таблицы (файл с расширением .$$$) разрастается до размера 4 гигабайт и Axapta 3.0 выдает ошибку следующего характера:
Ошибка в файле <Путь к файлу $tmp00300002.$$$>, в то время как запись в записи = FFFFEE20 Ошибка Windows: = Код ошибки 50110 = Превышен максимальный размер файла Система готова к завершению работы выход. Файловая система NTFS. В чем причина ошибки? |
|
02.08.2011, 12:43 | #2 |
Мрачный тип
|
Если реально на том хосте, где создается временный файл таблицы в памяти (а он создается там, где была создана первая запись, т.е. может быть и на клиенте, и на сервере), стоит NTFS - такого быть не должно. А можно поинтересоваться, что за задача такая и каков размер одной записи в таблице, что она разрастается до столь угрожающих масштабов ?
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|
02.08.2011, 12:52 | #3 |
Участник
|
реально NTFS и реально места предостаточно на том ресурсе где создается файл, в рамках эксперимента можно в цикле забить табличку временную. на 4 Гб начинает валиться на этом сообщении
|
|
02.08.2011, 14:36 | #4 |
Участник
|
Мне кажется, ограничение по размеру файла может быть не в файловой системе, а в движке ISAM, используемом для работы с временными таблицами и с теми же AOD-файлами. В любом случае, если у вас временная таблица такого размера, то это явно какой-то косяк в коде, создающем времянку, и код этот лучше переписать.
|
|
|
За это сообщение автора поблагодарили: Logger (3). |
02.08.2011, 14:41 | #5 |
Участник
|
с тем что код генерирующий временные таблицы такого объема надо переписывать полностью согласен, но интересно было именно узнать причину ошибки, склоняюсь к мнению gl00mie что это ограничение движка
|
|
02.08.2011, 15:47 | #6 |
Developer
|
Конечно ограничение движка, ибо в Axapta 3 и во всем что она использует нет даже намека на 64-х битную адресацию, а значит адрес последнего байта в файле не может быть больше 2^32 = 0хFFFFFFFF что есть 4 гига
|
|
|
|