Kent,

The normal procedure is to run the INACTIVATELOGS command
after a full backup so that only the logs necessary
to restore the active full backups, remain active.

It will only "break" the PIT restores if you do not have
your policy settings correct. If your policy settings
are set up so that you keep the inactive log backups,
they still can be used to apply to the
inactive backups to which they are associated.
On the flip side, if you have your settings so that
the inactive logs are deleted (RETONLY=0), then they
will be deleted and not available for recovery.

With Bill's strategy... he will be able to restore any
database and apply logs (with PIT, if desired) for up to 1 week.
For any database backup older than a week, he will only be able
to restore the full database backup... which is what I think
his goal was. Keep in mind... you can always restore a
full backup without applying any logs. In this case,
the database restored will be at the point of backup.

Thanks,

Del

----------------------------------------------------

Won't running INACTIVATELOGS immediately after a full backup potentially
break PIT restores from the prior full backups?  To preserve PIT restore
capability, it seems to me INACTIVATELOGS should be scheduled just before a
full backup, rather than after, and perhaps less frequently.  Also, for
PIT restores from older backups, don't you need to keep all transaction
logs at least as long as the oldest full backup?