Hoping someone can give me some help or point me in the right direction. I am attempting to use Collector to collect and update features and add photos as attachments. In Collector for iOS you can set the preferred resolution size. Collector will only let me up load small photos, any other option fails to upload.
I am using SQL express and ArcGIS for Server Advanced Workgroup. I am able to add large photos (>3,000kb) to the database though ArcMap and also ArcGISonline. But when I try from Collector with anything bigger then the small setting the upload spins for like two seconds then fails.
When I looked at the server logs I can see that any time I try to add an attachments larger than the small setting I get a severe error stating: Unable to process request. For input string: "18446744073709551615" and a Code:9003.
When I go to ArcGIS for Server 10.3 help there is no 9003 code.
Any ideas would be greatly appreciated,
"9003" might be a database error hinting on a corrupt database. As a small attachment might fit in a single datablock where larger attachment might need more (Just a thought, I didn't test this) you might test your database for consistency. There are many links on how to proceed with a 9003 error in your ms-sql database.
just my 0.02
Hey thanks for your input maybe I did not state it correctly. The error comes from the ArcGIS Server Manager log. Not the SQL express instance. I understand what you are getting at and I have also read that a corrupt database could be the problem. But after more testing I have found that I can add attachments of larger sizes to the database from ArcMap, ArcGIS Online, and the ArcGIS green app. I have tested this inside and outside of my local network and have had no problems with the attachments and no error codes logged. Yet every single time I try and add an attachment with Collector for iOS or Android it fails and the ArcGIS Server logs the error. It does not seem like a corrupt database or a networking issue on my end since I can add attachments just fine, but not with the Collector app.
Knew this looked familiar and fairly certain this was an issue we had.
<Msg time="2015-05-17T15:33:10,141" type="SEVERE" code="9003" source="Rest" process="5208" thread="32" methodName="" machine="XXX" user="XXX" elapsed="">Unable to process request. For input string: "18446744073709551614"</Msg>
So if this is what I am thinking then for us it was a RAM resource issue. Not knowing your environment and configuration I can't tell you exactly where to be looking. We run the Web Adaptors out on their own IIS servers and use the load balancing onto the ArcServers on their own servers. When we saw this, the issue was the RAM on our web servers was pegging out to 100% usage and users would wait to sync and get errors on the mobile device. We took this to be a timeout issue and the lack of resources prevented the data from getting through. Easy fix scaled out another 4GB of RAM and all was well again.
What's interesting is you are saying you can pass them through via ArcGIS Online which one would think should generate the same results as Collector. Perhaps consider leveraging the newer releases of Collector that allow for photo compression and verify file size between mobile devices vs what you are pushing into AGO.
We had a similar issue and needed to configure are webserver hosting the web adaptor to accept larger uploads. We added the following to our web.config file:
<requestLimits maxUrl="16384" maxQueryString="8192" />
Ah lol been over a year since we did these configs. We did this as well although don't believe it was what resolved this issue for us but still agree with Jade that this is good to change.
So running into similar issue again and digging back into things we saw that we had actually applied the below:
<requestLimits maxAllowedContentLength="2147483648" />
Attempted to add in the limits suggested by jebu23 but those made zero impact to the issue.
As I said above this has been a while back where we hit these (close to 2 years now) but I'll say yes because I honestly can't recall seeing this code anymore and we've had 400+ users collecting in production for a year or so. Our only issues have been a couple sync issues for which we have established some workflows for users to follow and has mitigated that as much as can be done. From what I recall on those issues it was in the early test stages and making this modification along with increasing the RAM on our web server VM's (we use n-tier architecture where the web adaptors are installed to web servers in a DMZ and ArcGIS is installed on an app server behind our internal firewalls so we scale resources different than a single server doing both jobs would) was what it took to eliminate any issues we were seeing with related to attachments.
I will add this, although it should have zero impact to seeing these codes from an ESRI standpoint, we have backdoored ESRI on our SQL DB end by implementing FILESTREAM for the management of the attachments. All transparent to ESRI just takes a little work but this does offload the storage of the picture/document from inside the DB onto an NTFS folder location which does change storage/size impacts.