06.02.2012, 14:20 | #1 |
Участник
|
Падает клиент при прикреплении файла
DAX 2009 SP1 5.0.1500.1313, SQL Server 2005 SP3. При сохранении записи с вложением превышающим по размеру 4 с чем-то метра падет клиент. Меньшие файлы благополучно сохраняет. Ошибка идентичная этой Пробовал и MaxBufferSize в реестр для АОСа и клиента пихать и на сиквеле с параметрами игрался, ничего не помогает. Есть ещё какие-нибудь варианты?
__________________
Самое полезное в жизни – это собственный опыт... Последний раз редактировалось Ashir; 06.02.2012 в 14:26. |
|
06.02.2012, 15:41 | #2 |
Участник
|
И что интересно, в логах никаких сообщений не возникает.
При этом скрипт X++: INSERT INTO myTable(FileName, Document) SELECT 'File1.pdf' AS FileName, * FROM OPENROWSET(BULK N'C:\Text.pdf', SINGLE_BLOB) AS Document;
__________________
Самое полезное в жизни – это собственный опыт... |
|
06.02.2012, 15:59 | #3 |
Moderator
|
Прикрепляемый файл берется с локального диска или с сетевого?
|
|
06.02.2012, 16:45 | #4 |
Участник
|
Файл берётся с локального диска. Клиент запускается на сервере там же где стоит АОС и Сиквел, права админские...
__________________
Самое полезное в жизни – это собственный опыт... |
|
07.02.2012, 01:31 | #5 |
Боец
|
- откройте конфигурационный файл клиента блокнотом
- добавьте в конце строку: maxbuffersize, text,0 - сохраните файл и запустите клиент, используя этот конфигурационный файл. Взято отсюда. Падает клиент при прикреплении документа Если не помогло, значит что-то неверное сделали. |
|
07.02.2012, 09:05 | #6 |
Участник
|
Цитата:
В разные места реестра пробовал [HKLM\SYSTEM\CurrentControlSet\Services\Dynamics Server\5.0] [HKLM\SYSTEM\CurrentControlSet\Services\Dynamics Server\5.0\01] [HKLM\SYSTEM\CurrentControlSet\Services\Dynamics Server\5.0\01\DAX50] Бесполезно. Кстати, maxbuffersize в реестре обнаружился только тут [HKLM\SOFTWARE\Microsoft\Jet\4.0\Engines\Jet 2.x], тип DWORD, десятичное значение 512.
__________________
Самое полезное в жизни – это собственный опыт... |
|
07.02.2012, 09:21 | #7 |
Moderator
|
Так все-таки, если клиент и файл находятся на одной и той же машине - проблема остается ?
Ну, и я бы еще один эксперимент провел - разместил бы файл на AOS и попробовал бы загрузить. Не очень понял этот момент из вашего ответа. |
|
07.02.2012, 09:22 | #8 |
Участник
|
Проблема однозначно остаётся.
__________________
Самое полезное в жизни – это собственный опыт... |
|
07.02.2012, 09:25 | #9 |
Moderator
|
Тогда - не знаю. У нас была похожая проблема, когда файл загружали с сетевой шары и при этом клиент работал на 64-ти разрядном сервере. Именно при сочетании этих двух факторов мы получали аналогичную ошибку.
Решили предварительным копированием файла на машину клиента и последующей загрузкой. |
|
07.02.2012, 09:29 | #10 |
Участник
|
Хм. У нас стоит Windows Server 2003 R2 Standard x64 Edition SP2, может с этим есть связь.
__________________
Самое полезное в жизни – это собственный опыт... |
|
07.02.2012, 13:38 | #11 |
Злыдни
|
А размер буфера RPC (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc, ключ MaxRpcSize (DWORD) значение 30000000 (30 Mb)) установили? Не забудьте, что параметры для текстового буфера применяются только после рестарта AOS
__________________
люди...считают, что если техника не ломается, то ее не нужно ремонтировать. Инженеры считают, что если она не ломается, то нуждается в совершенствовании. |
|
|
За это сообщение автора поблагодарили: Ashir (1). |
07.02.2012, 16:59 | #12 |
Участник
|
Предположу что проблема в том, что Аксапта имеет ограничение на размер контейнера при передаче его с клиента (приложения Аксапты ax32.exe) на сервер (службу АОС) так как он передается по значению, а не по ссылке.
А файл, с клиента на сервер (для его последующей записи в БД в вашем случае) передается в виде контейнера. Можно конечно попытаться изменить стандартные размеры RPC пакета для сервера, изменяя значения реестра... (как советовали выше, ранее обсуждалось на форуме...) Но есть альтернатива - передавать файл не одним общим контейнером, а делить его на части, передавать последовательно, и на стороне АОС "собирать" его вновь в одно целое. Для этих целей сделал два класса, которые позволяют передавать файлы любого размера средствами Аксапта (клиента и АОС) с клиента на сервер, и обратно. Процедура работает уже больше года, проблем в работе не вызывает. (Даже при передаче файла размером несколько GB ощутимого замедления скорости работы сервера АОС не замечено) Есть только одна странность - если в течении рабочей сессии на клиенте Аксапта использовалась данная процедура, то при закрытии этого клиента Аксапта, в некоторых случаях выдается сообщение об ошибке windows... Классы написаны для Ax2009. Пример использования: X++: DEV_FileSender::copyToServer("c:\\file.avi", "c:\\fileServer.avi"); (Заменить участки кода при сохранении итоговых данных) X++: binData.saveFile(_fileName); X++: serverContainer = binData.getData(); P.S Файлы докуметооборота Аксапты мы в БД не храним, а передаем (получаем) их с клиента Аксапта на файловый сервер именно этой процедурой. |
|
|
За это сообщение автора поблагодарили: sukhanchik (10), Logger (10), b_nosoff (1), Ashir (1), ivas (2). |
07.02.2012, 17:09 | #13 |
Участник
|
KiselevSA Да! Помогло, но как-то странно. Файлы до 10 с небольшим мегов сохраняет, а больше нехочет, говоря при этом "Размер распаковываемого контейнера превышает MaxBufferSize. При попытке вставить запись, содержащую контейнер, произойдёт сбой."
У меня MaxBufferSize имеет тит DWORD и значение 0 в ветках реестра относящихся к АОСу (указывал ранее), в файле конфигурации maxbuffersize,text,0 как писал DSPIC. Завтра поковыряю дальше...
__________________
Самое полезное в жизни – это собственный опыт... |
|
08.02.2012, 11:07 | #14 |
Участник
|
Вообщем подчистил свои мытарства в реестре, и сделал всё заново, а именно добавил 2 ключа в реестр
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc] "MaxRpcSize" тип DWORD десятичное значение 30000000 и [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dynamics Server\5.0\01\DAX50] "MaxBufferSize" тип REG_SZ значение 0 (до этого стоял DWORD, тестил блин) В итоге всё заработало. Файлы до 30 метров грузятся в базу. При этом для клиента никаких доп параметров MaxBufferSize нет ни в реестре ни в файле конфигурации. Место запуска клиента тоже не имеет значения, запускается ли он с сервера где стоит АОС либо с любой другой машины - не важно.
__________________
Самое полезное в жизни – это собственный опыт... |
|
|
За это сообщение автора поблагодарили: Logger (5), Ivanhoe (3), alex55 (1). |
31.01.2013, 19:36 | #15 |
Участник
|
Итоговый вариант помог, спасибо.
__________________
Ivanhoe as is.. |
|
31.01.2013, 19:41 | #16 |
Участник
|
А на клиенте игрались как? На клиенте этот параметр надо прописать в конфигурацию, которую клиент использует для запуска, соотв., она может быть как в реестре (причем не одна), так и в файле. В последнем случае параметр MaxBufferSize надо добавить в конфигурационный файл.
|
|
05.06.2013, 08:37 | #17 |
Участник
|
А после сохранения больших файлов, потом из таблицы записи выбираются? У меня выпадает ошибка
Невозможно выбрать запись в BinDataTable (BinDataTable). Из базы данных выбрано нулевое значение (NULL), которое не поддерживается. От такой ошибки помогло: maxbuffersize, text,0 Последний раз редактировалось Kainix; 05.06.2013 в 08:56. |
|
23.06.2014, 12:04 | #18 |
Участник
|
Можно ли при запуске аксапты программно узнать значение параметра maxbuffersize ? Чтобы в случае когда аксапта запускается без явного указания этого параметра в конфигурационном файле - выдавать какую-нибудь ошибку.
__________________
Дмитрий |
|
23.06.2014, 12:47 | #19 |
Участник
|
Открытых API для этого, насколько я знаю, нет. Можно анализировать параметры запуска клиента, выуживать оттуда путь к конфигурационному файлу и парсить его, либо лезть в реестр, если клиент запущен без конфигурационного файла.
|
|
23.06.2014, 12:50 | #20 |
Участник
|
Как программно узнать запущена аксапта с конфигурационным файлом в ярлыке или без него ?
__________________
Дмитрий |
|
Теги |
maxbuffersize, документооборот, загрузка, размер, файл |
|
|