If you have a database running in simple recovery mode, the transaction log
will grow, but eventually it will stabilize at a certain size, as sections
that are no longer in use get recycled. If your database is in simple
recovery mode, there is no need to truncate the transaction log, as this
will happen automatically.
As you say that you backup the transaction log to resolve your problems,
that means that your database is _not_ running in simple recovery, because
you can't backup the transaction log when the database is in simple
recovery.
There is more information in the Books Online article "Checkpoints and the
Active Portion of the Log".
--
Jacco Schalkwijk
SQL Server MVP
[quoted text, click to view] "Joe Jax" <jj@nowhere.com> wrote in message
news:OIcrkaQQFHA.2348@tk2msftngp13.phx.gbl...
> We have an data-intensive application that runs for several hours and
> produces a huge amount of data. The problem is that the transaction log
> gets very big very quickly and we have to frequently run a job to
> truncate, backup, and shrink the log. However, when the job is running we
> get connection timeouts and General Network Errors. We have no interest in
> maintaining a backup of the database and have no interest in maintaining a
> transaction log but yet we must do it. If the application fails, we just
> restore a copy of the database and begin again. Any advice appreciated.
>
> SQL Server 2000 Standard in simple recovery mode running on Windows XP
> Server 2003.
>
