Thom, I am not sure I understand why that is a bad thing to do.
Everyone, I could use some help with the following questions:
Why is it bad to shrink the log file?
Because it will (probably) only need to grow again to something near its original size as you perform more transactions. The auto-growth of the t-log file will cause a performance hit each time.
Why is a log file necessary if I am taking backups of database on a daily or sometimes hourly basis? If there is a crash, I would use the backup as the restore point.
As someone pointed out earlier, it's necessary b/c SQL won't work w/o one. You don't "need" it if you don't mind "sometimes" losing up to an hour's worth of work.:-) Seriously, if you or your business owners are satisfied with that risk of data loss (and you don't care about point-in-time recoveries), then you don't need to worry about transaction log backups and you could probably run in Simple recovery mode.
Honestly, I could probably tolerate losing 1 hour or even 3 hours' work on our prime d.b., if it happened once every 5 years or so. But I like knowing that I can do point-in-time recoveries to undo a stupid mistake, especially since I'm the one who will likely execute that stupid mistake! Think about it: my users work on one row at a time with a beta-tested web app. containing lots of built-in error-checking. I make updates across thousands of rows, often with one-off, ad hoc code that uses INT ID values I type by hand. Whose error is more likely to cause havoc system-wide?
Our log file seems to grow very large, and can easily be shrunk down from over 1GB to about 1000K. I did not think that was a bad thing until I started reading through some of the posts on this thread.
Thanks for all the information everyone is posting. I am learning a lot.
Jarrod
If you want to manage your t-logs, read the excellent articles posted here by others who have written about this admittedly sometimes confusing subject.
Yours,
Rich