SQL Log Rescue^™

Yes. The product has been designed to work with the very largest commercial databases.

The latest version of SQL Log Rescue is 1.1. If you are a current customer, you can upgrade to the version 1.1 by choosing Check for updates from the Help menu of the program. Please note that SQL Log Rescue's development is currently paused. As such, SQL Log Rescue is now available as a free download.

SQL Log Rescue only works with SQL Server 2000.

By visiting the relevant licensing page on this website, you can read full license details.

The activation server looks for the XML data in the activation request. HTML formatted emails make it difficult for the activation server to locate the activation request in the message, and when it's not found, the server simply gives up and discards the email. To prevent this, always ensure that activation requests via email are in plain-text format rather than HTML.

To use SQL Log Rescue you must have permissions to execute the SQL Log Rescue extended stored procedure (xp_LogRescue) in the master database. You must also be a member of the db_owner role for the database, or a member of the sysadmin role on the server.

Table drop is the only DDL operation displayed in the log entries list. However, changes to the table schema are taken into account if you undo or redo an operation.

SQL Log Rescue does not display modifications to schema objects in the log entries list. However, any operations resulting from the use of schema objects are shown. For example, if a stored procedure is run, this operation is not shown as a log entry, but any resulting data operations, table truncations, and table drops are shown.

When you perform a query using SQL Query Analyzer, SQL Server optimizes the query and executes it in the most efficient order. The log entries are shown in the order in which SQL Server executed them.

In some cases, an update is recorded in SQL Server 2000 as two separate log entries (a delete operation and an insert operation), and therefore SQL Log Rescue displays two separate log entries. For example, this occurs when the update affects a primary key or the location of the record in the clustering order, or if the row is marked for replication or is updated as a result of replication.

If the same update has been performed twice and the second update does not change the row data, SQL Server 2000 does not always record the second update in the transaction log, even if it was performed by a different user. Therefore, the log entry is missing from the list.

Note that tables that are dropped then reconstructed are not linked, because they are allocated different table ids by SQL Server. Therefore, when you group by tables, a table that has been dropped and then reconstructed will appear once to group log entries that occurred up to and including the drop operation, and a second time to group log entries that occurred after the table was reconstructed. If the table is dropped and reconstructed repeatedly, it will appear in the list multiple times.

Similarly, a table that has been dropped then reconstructed will be displayed in the Table filter menu multiple times if it has been dropped and reconstructed repeatedly.

SQL Log Rescue does not display updates to computed columns in the list of log entries, unless the computed column is a clustered primary key, a clustered index, or has a clustered unique constraint.

SQL Server 2000 does not always record the user who performs an operation in the transaction log. If this information is not available, SQL Log Rescue shows Unrecorded (-1) in the User column of the log entries table.

Similarly, if a user performs an operation but is subsequently deleted, the User column of the log entries table displays Unrecorded (n), where n is the user id if it is available, or -1 if it is not available.

The log entries list shows only operations recorded since the earliest included full database backup. Therefore, if no operations have been recorded since the full backup, the log entries list is empty.

To see log entries recorded prior to the full backup, create a new project, omit the recent full backup and, instead, include an earlier full backup to provide database history. Ensure that you also include transaction log backups to provide a contiguous record of transactions since the earlier backup.

If you do not include any transaction log backups in your project, SQL Log Rescue displays all the operations recorded in the live transaction log since the earliest included database backup (assuming the backup was created within the time period covered by the live transaction log, and it provides a full history). If you do not include any database backups within the period covered by the live transaction log, SQL Log Rescue displays all the operations recorded in the live log.