SQL Backtrack has a control file where you specifiy the number of
     version to keep.  Each and every 'object' presented to ADSM from
     Backtrack has a date/time stamp on it, and as far as ADSM is
     concerned, these are unique objects.  As such ADSM won't version them
     off.  It is the Backtrack api interface that is specifically telling
     ADSM what to delete.

     I still have several objects in ADSM that came from Backtrack.  The
     problem being that Backtrack doesn't know about them anymore, so they
     won't go away.

     Since there is no specific way to tell ADSM to forget all about an
     object it has in it's database, the only way to get rid of them would
     be to delete the 'filespace' which contains ALL the Backtrack backups.

     NOT QUITE RIGHT!

     BTW, these objects were created over a year ago under 2.1.0.3 or lower
     client and I don't remember what version of Backtrack.  We haven't
     seen any more occurances of this with the latest Backtrack with
     2.1.0.6 client.

     Regards,
     Al


______________________________ Reply Separator _________________________________
Subject: Re: sybase database & expiry
Author:  Naomi van Roosmalen <nvanroosmal AT NBTEL.NB DOT CA> at ~Internet
Date:    2/13/98 3:14 PM


Hello,
Thank you for your response. Does this mean that that data
can never be deleted? I know ADSM version 2 only allows for
deletion of entire filespaces which is not what I want. Does
SQL backtrack allow for deletion of files?

Naomi van Roosmalen

gmangum AT umich DOT edu wrote:
>
> SQL Backtrack generates a name for each backup copy which contains
> the date/time of the backup, so you never have extra copies as far
> as ADSM is concerned.   Each backup from SQL Backtrack to ADSM is
> considered by ADSM to be a new file.
>
> --
> Gene Mangum
> University of Michigan Medical Center