[rm-users] RE: (rm-users) Report Retention Issues with Brio P ortal 6.0

[Stephen Murphy]

We tried that but One/script only provides options to add a version to an
object or replace the object, not manipulate a specific version. If you
don't set an expiration date, the item stays forever. There is no system
default retention as far as we can tell. At this point we are thinking about
appending the date to our object names in order to break the objects apart.

--
*---------------------------------------------------------------------------
*
  Stephen T. Murphy  
  Manager, Database and Technical Support 
  University Business Systems - MSC-100
  The University at Albany, S.U.N.Y
  Albany,  New York    12222            
  Phone: (518) 437-4523     Fax: (518) 437-4540   <<=== New Numbers ===
  MailTo:SMurphy@UAMail.Albany.EDU     AIM: SMurphy199


> -----Original Message-----
> From: Hurt, Richard [mailto:Richard.Hurt@Tricon-Yum.Com]
> Sent: Tuesday, September 26, 2000 7:58 AM
> To: "'rm-users@sqrug.com'" ; "Stephen Murphy" 
> Subject: [rm-users] RE: (rm-users) Report Retention Issues with Brio
> Portal 6.0
> 
> 
>      Hmmm...couldn't you just delete a version just before 
> you attempt to 
>      insert a new one?  Also, what happens if you don't set a 
> expiration 
>      time in the ONE/Script for that report?  Does it default to the 
>      default timeout and not reset it every time?
>      
>      These are just a couple of ideas that flashed through my 
> head as I 
>      read your note, so they are probably really stupid.  :)
>      
>      Later...
>        Richard
> 
> 
> ______________________________ Reply Separator
> _________________________________
> Subject: (rm-users) Report Retention Issues with Brio Portal 6.0
> Author:  "Stephen Murphy" <SMTP:SMurphy@uamail.albany.edu> at Dallas
> Date:    9/25/2000 12:05 PM
> 
> 
> We are pushing a variety of documents into Brio.Portal. 
> Reports from our 
> mainframe use One/Script, outputs from our PeopleSoft system 
> use the API. In
> 
> either case, the reports are loaded as multiple versions of 
> an object. We 
> have discovered that we are not expiring old versions of our 
> reports so our 
> Portal repository just keeps growing. Sort of a roach motel, 
> reports check 
> in but the don't check out.
>      
> For example, a daily mainframe report is sent to Portal and 
> loaded using 
> One/script which creates a new version and sets a 7 day 
> retention period. 
> One would think the old versions would drop out after a week. 
> What happens 
> is every day, when the new version is added, the expiration 
> date is moved 
> forward 1 day. The report purging process does work correctly 
> if the report 
> frequency is less than the retention period. E.g., bi-weekly 
> job with 7 day 
> retention.
>      
> We reported this to Brio Support who responded that it is working as 
> designed but they did offer to open an enhancement request 
> for this issue. 
> (Not holding my breath for this.)
>      
> We have also tried to use the max versions parameter thinking 
> it would allow
> 
> us to age out content on the number of versions, rather than 
> age. When I set
> 
> the max on an object and then tried to load another version 
> of that object, 
> the One/script program balked with the message:
>      
>      "Error: maximum versions reached - delete a version 
> prior to adding
> a new one".
>      
> So my big question is: how do other sites automatically 
> manage the retention
> 
> of content within Portal?
>      
> --
> *-------------------------------------------------------------
> --------------
> 
> *
>   Stephen T. Murphy
>   Manager, Database and Technical Support 
>   University Business Systems - MSC-100 
>   The University at Albany, S.U.N.Y
>   Albany,  New York    12222
>   Phone: (518) 437-4523     Fax: (518) 437-4540   <<=== New 
> Numbers === 
>   MailTo:SMurphy@UAMail.Albany.EDU     AIM: SMurphy199
>      
>      
> _______________________________________________ 
> rm-users maillist  -  rm-users@sqrug.com 
> http://www.sqrug.com/mailman/listinfo/rm-users
> 
> 
> ---------------------------- 
> This communication is confidential and may be legally 
> privileged.  If you
> are not the intended recipient, (i) please do not read or disclose to
> others, (ii) please notify the sender by reply mail, and 
> (iii) please delete
> this communication from your system.  Failure to follow this 
> process may be
> unlawful.  Thank you for your cooperation. 
> ---------------------------- 
> 
> 
> _______________________________________________
> rm-users maillist  -  rm-users@sqrug.com
> http://www.sqrug.com/mailman/listinfo/rm-users
>