Charlie and Rick, Thanks for the feedback. I have used this in a similar fashion as the Incident Work Info section on a home-grown system here. We are actually going in that direction now because some of the Work information log data need to be sent to the customer for status. I didn’t think our engineers would want to use one diary field for work logging and another for customer status notices. We also frequently pass tickets between functional groups and will need to allow for tracking billable time. So it is going to be our method forward for most applications.
Theo, As for reporting, I’m using MS SQL Server 2008 and have not had time to work on MS SQL Server Reporting tool or BIRT to make some canned reports. I’ve tried joins and the multiple parent record fields are an issue with people who use .csv exports to excel. They’re also the ones who complain about too much data in a diary field getting truncated in excel. So I’m hoping I can come up with a way to filter unnecessary records from the Work Information table. Misi, You always seem to have tool on the shelf for everyone’s needs. Thanks, I’ll take a look at it when they ask me to convert the archived diary field data to individual records. You both mentioned sub-reports. Is this something external to the BMC Remedy report engine? Like BIRT or MS Reporting. We don’t have a Crystal Reports web service. Thank you, --- John J. Reiser Remedy Developer/Administrator Senior Software Development Analyst Lockheed Martin - MS2 The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Charlie Lotridge Sent: Monday, September 29, 2014 7:18 PM To: [email protected] Subject: EXTERNAL: Re: Diary field usage ** I can't speak to "best practices", but IMHO it really depends two things: the expected size of the content and how you plan to use it. With regard to the expected content, if you're planning to document something with a relatively limited life-cycle and not a lot of content, then I think diary fields are an excellent choice: they're very easy to create and maintain and don't require setting up the child form, workflow, and UI needed to support it that the "PK/FK" paradigm requires. But if you're planning to document something with an indefinite life-cycle, where the content may grow continuously, then diary fields become a bad choice. Remember that these are stored in your DB as a blob (text, ntext, etc), so the entire content needs to be read and written on each access or update (respectively). What's worse is that this entire content needs to be transferred over the wire multiple times (from DB to ARS to mid-tier to client and back again). This obviously gets cumbersome when the content is very large. With regard to planned usage, if you're planning on setting up complex searching (or reporting) on the content, diary fields are difficult to use. On the other hand, if you plan to use the content only for review (e.g. users will only need to read through them to see what happened and when), then diary fields are perfect for the job. Hope this helps. -charlie On Mon, Sep 29, 2014 at 3:35 PM, Rick Cook <[email protected]<mailto:[email protected]>> wrote: ** Yes, they are not the best practice any more. Best practice is to accumulate records in a back-end form and use a PK/FK relationship to tie them to a master record (i.e. Work Logs to an Incident. Reporting can be challenging, but a join at the reporting level should make things easier. Rick Cook On Mon, Sep 29, 2014 at 3:30 PM, Reiser, John J <[email protected]<mailto:[email protected]>> wrote: ** Hello Listers, I have quick question. What is the general consensus on the use of Diary fields? Are they going out of style? I have tried a “work log” table type of design to replace the diary function on a form. This method works ok except when it comes time to run reports. Do you dump the table field data to a large character field? Or is there a slick way to incorporate the child records into the report on the fly? Thank you, --- John J. Reiser Remedy Developer/Administrator Senior Software Development Analyst Lockheed Martin - MS2 The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me _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"
