Resolved (partially).
Thanks to some help from Ganesh Gore and Jason Miller I was able to identify a workaround. Part of the data I was receiving from the web form was some information related to the attachment, specifically: 1) FileContentType - which tells me the type of file it is (i.e. text) 2) FileName - which gives me the full name of the file (i.e. test.txt) 3) FileSize - which gives me the file size in KB. I was able to use the PERFORM-ACTION-SAVE-ATTACHMENT Run Process command to save the attachment as provided in the view form to the server file system (and append the FileName field value to the save, thus defining the attachment), then used the , PERFORM-ACTION-DELETE-ATTACHMENT to delete the existing attachment with no file extension and finally use the PERFORM-ACTION-ADD-ATTACHMENT to re-add the attachment (saved in step 1) with the correct name/extension. BMC Engineering is still on the hook to identify the bug in the code line that 1) causes the server to crash on a push and/or 2) doesn’t recognize the attachment values on a set fields. Thanks Ganesh and Jason! Tim P. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Timothy Powell Sent: Wednesday, July 15, 2015 5:42 PM To: arslist@ARSLIST.ORG Subject: Re: View Forms and Attachments ** Follow-up. I have now tested this on an ARS 8.1 server with the same results. I am still doing a set fields FROM the view form TO the staging form where View Form Request ID (VFRI) = the stored value of the VFRI on the staging form and setting the attachment. I have an attachment on the staging form now, but ARS doesn’t know what it is (in terms of a file type), isn’t showing the right file name or file size and can’t open it (again because it doesn’t know what the file is and thus doesn’t know what to use to open it). IMHO, the API should “get” all the file attributes and display the attachment to me in the proper format. Anybody have any other ideas? Thanks in advance, Tim From: Action Request System discussion list(ARSList) [ <mailto:arslist@ARSLIST.ORG> mailto:arslist@ARSLIST.ORG] On Behalf Of Timothy Powell Sent: Monday, April 27, 2015 12:34 PM To: <mailto:arslist@ARSLIST.ORG> arslist@ARSLIST.ORG Subject: Re: View Forms and Attachments ** Thanks Doug. I did open a support ticket. As a follow-up. I added the extra step of doing a set fields FROM the view form TO the staging form where View Form Request ID (VFRI) = the stored value of the VFRI on the staging form and setting the attachment. That works. Sort of. I have an attachment on the staging form now, but ARS doesn’t know what it is (in terms of a file type), isn’t showing the right file name or file size and can’t open it (again because it doesn’t know what the file is and thus doesn’t know what to use to open it). I thought the API would “get” all the file attributes. SQL view of attachment data for this record (staging form): Attachment details table Shown as Column/Value: C1 000000000000003 C1000003962 142832058031219_File1BinaryData CO1000003962 2 CC1000003962 2 Attachment data table: entryId 000000000000003 C1000003962 0x1F8C0200020000000BD103006087D843 Tim From: Action Request System discussion list(ARSList) [ <mailto:arslist@ARSLIST.ORG> mailto:arslist@ARSLIST.ORG] On Behalf Of Mueller, Doug Sent: Friday, April 24, 2015 4:13 PM To: <mailto:arslist@ARSLIST.ORG> arslist@ARSLIST.ORG Subject: Re: View Forms and Attachments ** Timothy, I will start with the statement that a crash is NEVER EVER an INTENDED consequence. So, by definition, it is an un-intended consequence. Attachment fields have a very specific storage format in the AR System. My guess is that when we map a view field including attachments, there was work done to allow for that, but there was not testing done to see what if you now try to use that attachment on a view as a source or target of workflow assignment. I am not saying that this should not have been tested, but I suspect it was not and you have found a bug in this operation as LJ has indicated. I would open a support case with the specific operation you are attempting. There should be no reason for the logic not to work. And, it is never acceptable for the server to crash. Doug Mueller From: Action Request System discussion list(ARSList) [ <mailto:arslist@ARSLIST.ORG> mailto:arslist@ARSLIST.ORG] On Behalf Of Timothy Powell Sent: Friday, April 24, 2015 11:54 AM To: <mailto:arslist@ARSLIST.ORG> arslist@ARSLIST.ORG Subject: Re: View Forms and Attachments ** LJ, Thanks for the quick reply. Ok, so you’re saying that I am doing this correctly and the crash is an un-intended consequence? TP From: Action Request System discussion list(ARSList) [ <mailto:arslist@ARSLIST.ORG> mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Friday, April 24, 2015 2:16 PM To: <mailto:arslist@ARSLIST.ORG> arslist@ARSLIST.ORG Subject: Re: View Forms and Attachments ** Tim, I regret to inform you that you have found a bug in BMC's server. You should not be able to do anything to crash a server, period. I see that you are already running the latest SP of your version, so I can't recommend doing anything other than contacting BMC and hope for a hotfix that addresses your issue. :) On Fri, Apr 24, 2015 at 12:00 PM, Timothy Powell <timothy.pow...@pbs-consulting.com <mailto:timothy.pow...@pbs-consulting.com> > wrote: ** ARS 7.6.04 SP5 Microsoft SQL Server 2008 R2 (SP1) Concept: I have an external web form. People enter data into said form. That data includes attachments. That data is posted to a database residing on the same database instance the ARSystem DB resides on. Attachment data is posted to a SQL Image column. I have created a view form to see the posted data. Per page 190 of the 7.6.04 Integrations Guide: # Beginning with release 7.6.02, view forms support additional data types. This includes blobs (DB2, Oracle, and Informix) and images (Microsoft SQL Server and Sybase), which map to an attachment field When I add the external columns to my view form, the ARSystem does indeed automatically create an attachment field inside of an attachment pool for the SQL Image column. I can see all data stored on the external DB including the image data (although the properties are not displayed properly). **************** Next step: Now I want to move that external posted data from the view form and into a native ARS staging form where I can massage the data and move it to its final destination within the ARSystem application. I created a filter to push the data from the external DB to my ARS staging form. When I map the fields, if I leave the attachment field out of the Push Fields mapping, everything works great. When I map the fields and I INCLUDE pushing the image data to an attachment field on the ARS staging form, the system throws a Signal and dies; error below: Fri Apr 24 11:57:01 2015 390620 : AR System server terminated — fatal error occurred in ARSERVER (ARNOTE 21) Fri Apr 24 12:02:46 2015: AR System server terminated when a signal/exception was received by the server (ARNOTE 20) Thread Id: 2856 Version: 7.6.04 SP5 201308012025 Aug 1 2013 21:00:12 ServerName: *********DVARS1 Database: SQL -- SQL Server Hardware: x86_64 OS: Windows Server 2008 RPC Id: 325779 RPC Call: 183 (SGE) RPC Queue: 390620 Client: User tpowell from Remedy User (protocol 18) at IP address xx.xxx.xxx.xxx Form: WebSubmitHolder Logging On: Code: c0000005 Operation: read Access Addr: 0000000000000000 Stack Begin: Addr: 000000007460814D Addr: 0000000000000001 Addr: C300000001B80674 Stack End I'm obviously missing something. Any ideas? Thanks in advance. Tim Powell _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
