From: reb01501@NOSPAMyahoo.com   
      
   Cathy wrote:   
   > Perhaps I am confusing the issue by providing too much details and   
   > getting things sidetracked   
   >   
   > Lets forget about how many files there are and how many databases.   
   >   
   > My question is as before   
   >   
   > what is the simplest to   
   > 1. close any open transactions in the log file   
      
   Run CHECKPOINT   
      
   > 2. take it offline if needed   
      
   Not needed.   
      
   > 3. Truncate it if needed   
      
   BACKUP WITH TRUNCATE_ONLY   
      
   > 4. Shrink the database (sorry I realise my error now saying logfile   
   > before)   
      
   NEVER shrink a database. You can shrink a log file if you think you know   
   what size it should be (a good rule of thumb is twice the size of the   
   largest table in your database, but that might be too large - there's some   
   trial and error involved) but never shrink a database's data file.   
   http://www.sqlskills.com/blogs/paul/post/why-you-should-not-shri   
   k-your-data-files.aspx   
      
   > 5. backup the database   
   You've done nothing to necessitate backing up the database as long as you   
   already have a good backup schedule.   
      
   > 6. bring the database online again   
      
   Again. Not needed   
   >   
   > Imagine this is one database (whether simple of full recovery model)   
   > I am hoping for a single TSQL Script I can use   
   >   
   Personallly, I use SSMS - you can tell it to script your actions if you must   
   have a script. But as Erland told you, the scripts will be different for   
   each database log you work on.   
   Oh, and did I mention that the only files you should consider shrinking are   
   the log files? I hope I made it clear that data files should never be shrunk   
   ...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)