From: anton.txt@g{oogle}mail.com   
      
   Erland Sommarskog:   
      
   > Since the log is truncated on checkpoint, the log could   
   > look empty.   
      
   Indeed.  I wish I knew how to track LSNs more reliably.   
      
   > Then again, if you track LSN:s you should be safe.   
      
   Do you mean your suggestion to use `RESTORE HEADERONLY'?  If   
   so, I have already remarked that its FirstLSN LastLSN fields   
   are also available from the msdb.backupset table.   
   Unfortunately, tracking them produces a lot of false   
   positives, because of all the event types, I need only those   
   that refer to data changes, that is:   
      
         LOP_INSERT_ROWS, LOP_MODIFY_ROW, LOP_DELETE_ROWS   
      
   Other events should not trigger a backup.   
      
   > > I believe my situation is not unique, when there are   
   > > many infrequently used databases and no requirement of a   
   > > 15-minute backup granularity, so that keeping the simple   
   > > recovery model and doing a backup /only/ when data has   
   > > changed safes a log of resources.   
   >   
   > Log of resources, hehe. :-)   
      
   Of course, so that nothing slips by.   
      
   > Then again, following the normal routines saves quite a   
   > bit of human resources.   
      
   At the expense of increased boredom, and customisation.   
      
   --   
   ()  ascii ribbon campaign -- against html e-mail   
   /\  www.asciiribbon.org   -- against proprietary attachments   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)