We were able to *mostly* do this with a custom BIRT report built using BIRT Designer. I say mostly because it doesn't export to Excel too well. The spreadsheet needs some tweaking before you can get a true sortable/filterable spreadsheet. I have read the version of the emitter included in BIRT shipped with Mid Tier is an older version (Apache Axis anybody?) and newer versions of the emitter work better.
The reason this was not going to work for us on the project I just mentioned in my last reply is we a requirement that end-users needed the ability to build their own reports vs. our team building them in BIRT designer. Jason On Tue, Sep 30, 2014 at 12:49 PM, Misi Mladoniczky <[email protected]> wrote: > Hi, > > I have done Sub-Reports in Crystal, but I presume that it would be easy > enough > in BIRT. > > If you get intimidated by the config of RRR|DiaryX, let me know, and I will > walk you through it. > > Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) > > Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13): > * RRR|License - Not enough Remedy licenses? Save money by optimizing. > * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. > Find these products, and many free tools and utilities, at http://rrr.se. > > > 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" > > > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "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"
