Melinda Varian wrote:
>
> We've just begun using the Backtrack interface to ADSM for backing up
> some Sybase databases.  We have one problem and one question and would
> be grateful for assistance on either:
>
> Problem:
>
> On a test, we received the following messages (this is just a snippet,
> most messages signaled good completion):
>
>   [obsi/adsm 16680] obsi/adsm: ADSM: dsmSendObj failed: (2061)
>   On dsmSendObj, dsmDeleteObj, or dsmUpdateFS the filespace isn't
>   registered.
>
>   [obsi/adsm 16680] obsi/adsm: ADSM: dsmEndTxn failed, return code:
>   (2302)   The dsmEndTxn vote is ABORT, so check the reason field.
>
>   [obsi/adsm 16680] reason code: (3)      Client ended transaction
>
>   [dtsdump 16673] *** Interrupted "TIGER report table dbo.pd_adjust:
>   0.1% 400 of 481,085 rows u..." on 10/01/96 16:17:56
>
>   16:17 backup of /dbms/dtbackups/sybase/TIGER/report completed with
>   errors
>
> Question:
>
> What is the best approach to compression?
>
>   ADSM-NO,  Backtrack-NO
>   ADSM-NO,  Backtrack-YES
>   ADSM-YES, Backtrack-NO
>   ADSM-YES, Backtrack-YES
>
> Thanks for any help.
>
> Melinda Varian,
> Princeton University

Melinda,
We run with ADSM-NO,  Backtrack-YES here.  We wanted to use compression,
but knew that compressing the data twice was unnecessary (the second
compression buys you nothing), so it came down to using the compression
provided by SQL-BackTrack or ADSM.  I chose to use SQL-BackTrack's
because I felt it would minimize finger pointing should compression
related problems arise.  (ie DataTools can't blame IBM).

Jim