All SQL transactions performed on TBS database level will be logged in TBS_BAWSE.ldf. The number of SQL transactions could be very big when there is a large number of connected TBS clients and users. This means the size of the DB transaction log file will increase continuously over time.
These SQL transactions have to be clearly distinguished from Time and Attendance transactions: these are general database transactions and thus any operations at database level is logged to ensure rollback possibility.
These SQL Server log files are VERY important and should not be simply deleted !!!
Some details about LDF files (excerpts from internet articles): While data is stored in an MDF file, all transactions and the SQL Server database modifications made by each transaction are stored in an LDF file – a transaction log file which is an essential component of the database. Conceptually, the log file is a string of log records. Physically, the log records are stored in one or the set of physical LDF files that implement the transaction log.
The primary purpose of an LDF file is to provide the ACID concept – Atomicity, Consistency, Isolation, and Durability:
- Atomicity: if one part of the transaction fails, the entire transaction fails, and the database state is left unchanged
- Consistency: any transaction brings the database from one valid state to another
- Isolation: the execution of concurrent transactions brings the database to a state as if the transactions were executed serially, one by one
- Durability: once committed, the transaction remains, even in the case of errors, power loss, or crashes
An LDF file stores enough information to replay or undo a change, or recover the database to a specific point in time.
Solution
To keep the size of this file under control, regular maintenance has to be carried out.
TBS recommends to:
- Backup the TBS_BAWSE database regularly (daily/weekly/monthly - depending on the size of the installation). The backup process itself could already help to reduce the filesize. This means that a regular backup routine helps to mitigate this problem from the start.
- Shrink the transaction log once or twice a year (or more often if really needed) always directly after a backup was taken, using SQL Management Studio.
Please consider this article on how to create backups:
For guidance on how to shrink the log file please review the below articles: