InfoPath Dev

I already have the SaveToSharePoint command running great on a handful of InfoPath forms, however, I programmed an attachment to run it recently on a new form and when I test it via preview mode, it works great. I attach the file and it uploads to the the document library as expected.

However, once I publish the InfoPath form and attempt to attach a file, it doesn't upload and instead returns the error: Failed while checking for existing file: The remote server returned an error: (500) Internal Server Error.
I have no idea why it would be checking for an existing file.

I can see that other users are uploading the files successfully via the same attachment field.

I have full access to the entire SharePoint farm and opened up the actual attachment library just fine, so permissions and network access don't seem to be the issue.

Any ideas on what would cause this error for me only?

 Is this form being used in the browser or the filler?

Filler.  I have verified this under the Form Options as well.

 What is the command you are using? The full syntax (I realize you are using SaveToSharePoint, but want to know what parameters you are using).

SaveToSharePoint /url=siteURL/CCF Attachments /xpath=/my:myFields/my:group7/my:group10/my:Attachments/my:attachments /namexpath=@my:newAttachmentName

I have the name being applied from the newAttachmentName field because I run a command to remove any odd characters from the name path first and the "cleaned" file name is then placed into the newAttachmentName field.  

 Thanks - it is odd to me that you are getting an error about checking for existing - that should only be happening if the overwrite param is included. It is even odder that you get the error and other users don't. I'd like to take a look at your form - could you either attach it under the Options tab here in a reply or email it to support AT qdabra DOT com and reference this thread? I want to look at the qRules DLL. :)

I pinpointed when the error is occuring exactly. 
I implemented the SaveToSharePoint command to a form that has been in use for a few years now.  We were having problems opening some of the forms due to the large attachments attached to them.  Therefore, I am implementing the SaveToSharePoint feature to remove the attachments from the form and save them into a library instead. 

I found that I get the error only when I open an existing form that has an attachment already attached and I try to attach a new attachment. 

I was hoping that the SaveToSharePoint command would automatically run when I open the form, but it doesn't.   I was testing the command by adding a 2nd attachment (the attachment field is in a repeating section) and that's when I got the error.  However,  I found that if I removed the original attachments, then reattached them, it worked correctly. 

Thank you for your time!

 No - the command won't run automatically. You could add a rule to the Qdabra Rules finishedLoading node and if that node = true, you could execute your SaveToSharePoint command - that would have the same general effect.

Thank you for the finishedLoading idea. I did it and it kinda works.  But because the attachment is in a repeating section, it seems to keep messing up.  but I am not so worried about that.

Now when I try to upload an attachment that is fairly large in size (24MB), I am getting this error: .

Details: Exception of type 'System.OutOfMemoryException' was thrown.. Stack: at System.Convert.FromBase64String(String s)
at Qdabra.Tools.RulesLibrary.Commands.GetBase64Values(String base64Value, String& fileName, String& fileExtension, Int32& fileSize, Byte[]& file)
at Qdabra.Tools.RulesLibrary.Commands.SaveFileToSharepoint_Client(XPathNavigator fileNode, String& url, String requestedFileName, String fileNameXPath, String overwriteExisting, String dsnameprog, String xpathprog, String copyServiceName, String copyServiceUrl)
at Qdabra.Tools.RulesLibrary.Commands.SaveToSharePoint_Client(String url, String domName, String nodeXPath, String fileName, String fileNameXPath, String overwriteExisting, String async, String dsnameprog, String xpathprog, String copyServiceName, String copyServiceUrl, Boolean clear)
at Qdabra.Tools.RulesLibrary.Commands.SaveToSharePoint()
at Qdabra.Tools.RulesLibrary.Commands.RunCommand(String commandName)
at Qdabra.Tools.RulesLibrary.Commands.ExecuteCommand()

 Do you know what could be causing a OutofMemoryException error?  Does this mean the file is too large?   Is there a workaround?

Thank you!

 Okay - first, qRules SaveToSharePoint handles attachments in repeating sections or groups, so I would be interested to hear more about how it is messing up. I would like to look at your form if possible - you can attach it under the Options tab in a reply, or sent to support AT qdabra DOT com and please reference this thread.

I'm going to ask one of our testers to reproduce the issue with a large attachment & I'll let you know what we learn. 

Sending form in an email now.  Thank you.

 So - you are definitely going to have an issue with your rule on finishedLoading that is running the GetAttachmentAttribute command - that command is not going to loop through all the instances of your attachment group. When you set the attribute for the new attachment name (@my:newAttachmentName) from any rule outside of the repeating group, you'll end up setting all of them to the same value.

 It would probably be easiest at this point to add a helper field here /my:myFields/my:group7/my:group10/my:Attachments called "SetAttachmentName" or something and copy your rules that are currently on the Attachment field to the new helper field..... Then, on form load, you could set SetAttachmentName to true, which would set all instances, and if the attachment name hasn't been populated yet, you could run the logic to generate each unique attachment name. Does that make sense?

Then when you run the SaveToSharePoint command you won't be overwriting the same file when there are multiple attachments already in the form. 

 I wonder if this error may be machine related - I just tried SaveToSharePoint with a 30 mb file and had no issues - our tester had an issue with at 17 mb file, however.....

Interesting.  I don't shut my computer down every day so when I start to experience inconsistent odd occurances such as this, I do a reboot and try again.  And what do you know, after I rebooted, I was able to upload the same large attachment I tried to upload yesterday. 

 Oh, fascinating. Thanks for the update. Did the info on setting the attachment name make sense?