4) With 20 attachment fields in the pool, you will end up with a scroll bar unless you make the field unusually tall. Users could add an attachment to any one of the 20 fields without filling in the others. If they chose to add one to a field that is only seen when you scroll down, other users looking at the ticket might not see the attachment. I don't know why they would do that, but if they can, they will. Having the attachments in an external form and displayed as a table will keep that from happening.
Thad Esser Remedy Developer "Argue for your limitations, and sure enough, they're yours."-- Richard Bach "Bryan Waters" <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" <[email protected]> 12/14/2007 09:11 AM Please respond to [email protected] To [email protected] cc Subject Re: How many attachments? ** Kevin, I would recommend that you store attachments in a separate centralized data table. This will provide 3 main benefits: 1) The load time of a ticket will be less since the attachments do not have to be fetched when querying. 2) You are not bound to a finite number of attachments. Use a GUID value to relate the data ticket to the attachment records. This will allow a ?n? number of attachments. 3) You can reuse the centralized attachment form for other applications Cheers, Bryan From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Amen, Kevin Sent: Friday, December 14, 2007 11:26 AM To: [email protected] Subject: How many attachments? ** Are there any "gotchas" with having 20 attachment fields in an attachment pool? Kevin Amen Novartis Vaccines & Diagnostics Information Technology 510.923.3691 (Office) / 510.520.4060 (Cell) __20060125_______________________This posting was submitted with HTML in it___ Email Disclaimer This email has been sent from the TuringSMI Group This message is subject to and does not create or vary any contractual relationship between TuringSMI, SMI Technologies, SMI Telco, its subsidiaries or affiliates and you. Internet communications are not secure and therefore the TuringSMI Group does not accept any legal responsibility for the contents of this message. Any views or opinions expressed are those of the author. This message is intended for the addressee(s) only and its contents and any attached files are strictly confidential. If you have received it in error, please contact the sender on the number above. __20060125_______________________This posting was submitted with HTML in it___ ***IMPORTANT NOTICE: This communication, including any attachment, contains information that may be confidential or privileged, and is intended solely for the entity or individual to whom it is addressed. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message is strictly prohibited. Nothing in this email, including any attachment, is intended to be a legally binding signature.*** _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
