ApexSQL Knowledgebase

How to change default application when more than one application instance is installed.

2010-03-09T03:33:00.005-05:00

SUMMARY

This article is showing how to set default application when more than one instance of same application is installed.

SYMPTOMS

Although file association for .sql files is set to newly installed ApexSQL Edit, double click opens file in older version.

CAUSE

Windows file association is pointing to the wrong instance of application.

RESOLUTION

To change this association to newly installed application, you should change one registry key.
Start registry editor by typing 'regedit' without quotes into the Run dialog.
Find folder HKEY_CLASSES_ROOT\Applications\ApexSQLEdit.exe\shell\open\command and change path in Default key to match your newly installed application.

SEE ALSO

How to associate .SQL files with ApexSQL Edit?

LAST REVIEW

9 March 2010

How to send email alerts when a change is made to a database record

2010-02-08T12:32:00.006-05:00

DESCRIPTION
This article discusses how to customize the ApexSQL Audit architecture so that email alerts are sent out when changes are made to a database record.

These instructions make use of Database Mail and can only be used if you're using MS SQL Server 2005 or MS SQL Server 2008.

SOLUTION

1) Configure Database Mail.

2) Download ApexSQL2049_Mail.audx here. This architecture is specifically customized to allow for the sending of email alerts when a change occurs. Save this file in ApexSQL Audit's application folder. For example, C:\Program Files\ApexSQL\ApexSQLAudit2008.

3) Start ApexSQL Audit and connect to the database you want to audit.

4) Click File | Select Audit Architecture and select ApexSQL2049_Mail.audx.

5) Click File | Template Editor to modify the template.

4) Next, find and modify the following lines of code. Base the values you set here on how you set up your Database Mail.

'Customize values below
Mail_Profile = "John"
Mail_Recipients = "John@mymail.com"
Mail_Body = "Please verify database change."
Mail_Subject = "Unauthorized Database Change"

5) Click Run | Process and save the architecture file.

6) Close the Template Editor.

7) Create your triggers. If you have triggers set up already, they would have to be recreated if you want them to use the new architecture template.

What happens next? Triggers created using this template, when fired, will not only store audit data but will also send email alerts indicating that a change has been made.

Written by:
Janice Lee

Last Modified Date:
2 Feb 2010

Object-level differences in ApexSQL Diff CLI

2010-01-19T14:56:00.000-05:00

Sometimes it is helpful to see objects differences while comparing data sources in CLI mode of ApexSQL Diff application. This feature is available in ApexSQL Diff

Comparison summary.
ApexSQL Diff now shows comparison results in CLI in text mode.

Object level differences.

Object level differences information is displayed in form of table with three columns “Name”, “Owner” and “Result” for each compared object. These tables are grouped by object type that are compared the way objects are grouped in ApexSQL Diff GUI.

Result column can have one of the following values:

1) == - if compared objects are equal;

2) <> - if compared objects differs;

3) >> - if object exists only in source data source and does not exist in target data source;

4) << - if object exists only in target data source and does not exist in source data source;

In case if database objects have different owners and mapped, both owners will be displayed in result objects table.

In this case tables “AWBuildVersion” and “ErrorLog” has “Person” owner in source data source and “dbo” owner in target data source.

Script-level differences.

For each compared object, ApexSQL Diff displays its script. If objects are different, it also shows exact differences on script level (the way similar to ApexSQL Diff GUI).

First two symbols of each line of the script have one of the following values:

1) == - if lines are equal in source and target scripts;

2) >> -displays line from source script (in case lines if source and target scripts are different);

3) << - displayed line from target script (in case lines if source and target scripts are different);

For example, String data type is displayed like:

From this screen you can see that String data type differ in second line of script.

Source script contains FROM [varchar](150) line

Target script contains FROM [varchar](100) line

All other lines are equal for both scripts.

When object exists only in source or in target data source, the whole object script is displayed using “>>” and “<<” prefixes.

The summary and details information are displayed if /v switch is specified for CLI comparison. The information is displayed in standard output stream, so it can be redirected to the file for further analysis and saving.

Get your developers the tools they need to do the job fast and right - ApexSQL Developer Studio is the ultimate combat multiplier for SQL Developers. Best of Class tools - one download, install and discounted price. Click Here for more info.

How do I upgrade ApexSQL Refactor?

2010-01-18T06:39:00.019-05:00

DESCRIPTION
This article describes how to upgrade ApexSQL Refactor

SOLUTION
Download the latest version of ApexSQL Refactor here. The free version is no longer offered for download but a freeware version of the current ApexSQL Refactor may be available soon.

Before starting ApexSQL Installer, be sure that SQL Server Management Studio is closed. Start Setup wizard and install ApexSQL Refactor add-in over existing one.

After upgrading to the latest ApexSQL Refactor 2010 version, in some cases when starting Microsoft SQL Server Management Studio, remove add-in dialog displays with the message that ApexSQL Refactor add-in is failed to load or causes an exception.

Click Yes to remove ApexSQL Refactor add-in. Then please start ApexSQL Refactor uninstaller and from its dialog select Yes for removing all existing ApexSQL Refactor versions.

Execute installer again and install the latest ApexSQL Refactor version again.

After performing these steps you should be able to execute Microsoft SQL Server Management Studio and use ApexSQL Refactor add-on without any problems.

AUTHOR
Dragana Ilic

LAST REVIEW DATE
18 January 2010

ApexSQL Log update to the latest public version

2010-01-12T08:12:00.006-05:00

DESCRIPTION
ApexSQL Log auto-updater updates the client side of the application only. So server-side components and Connection Monitor from the previous version of ApexSQL Log still reside on the SQL Server and are running. This part of the application needs to be updated manually.

Server-side components update could be performed in the two ways:
1. Through the Connection Monitor Manager dialog: the Connection Monitor is fully configurable from the application GUI (Tools | Connection Monitor Manager) starting from the ApexSQL Log 2008.05. Application offers server-side components update, otherwise Connection Monitor management will not be available.

Connection Monitor Manager dialog consists of the two tabs: Connection Status and Data Capture that enable to manage Connection Monitor Log On options as well as a possibility to enable/disable the monitor and to choose a database for storing captured data.

Connection Status tab contains information about selected server, log on type, connection monitoring state and status.

Data Capture tab contains settings for:
1. Database where user wants to store login information
2. Captured information maintenance

Custom database to store login information could be selected here with the automatic or manual maintenance of the captured information.

2. Application automatically offers server-side components update at first auditing: since old server-side components are not compatible with the latest client, without this update auditing will not start.

However even after the server-side components are updated the Connection Monitor keeps saving data into msdb.APEXSQL_LOG_LOGIN table. This behavior can be changed through the Data Capture tab of the Connection Monitor Manager dialog (click here for more details ).

Note: After the application is auto-updated you need to manually run vcredist_x86.exe which is updated and placed into ApexSQL Log installation folder (e.g. C:\Program Files\ApexSQL\ApexSQLLog2008) on the machine where SQL Server is installed. This installer requires for correct work of server-side components.

AUTHOR
Dmitriy Dyubchenko

LAST REVIEW DATE
12 January 2010

How do I restore the original layout of my application's interface?

2009-11-25T07:41:00.008-05:00

Introduction
The layout of the interface of your ApexSQL tool can be customized to your liking. For example, you can move toolbars around or hide them. You can also change the dimensions of your dialogs. When you make changes like these, how do you restore your layout to the original settings? That is, how do you make your application look as it did when you initially installed it?

The file called layouts.xml stores your application's layout. This file can be found on your application's installation folder (e.g. C:\Program Files\ApexSQL\ApexSQLDiff2008\layouts.xml). The following are stored in this file:

- Whether your application window is minimized or maximized when you start your application
- Dimensions of your application window and dialogs
- What toolbars and menus are displayed
- and more.

When you exit the application, Layouts.xml is saved.

How do I restore the original layout of my application's interface?
So to restore the original layout, do the following steps:

1) Close the application.
2) Go the application's installation folder.
3) Delete layouts.xml.
4) Start the application.

The layouts.xml file will be re-created and your interface will be restored to its original settings.

See Also
Losing your customized layout after an upgrade

Last Modified By
Janice Lee
2/10/2010

How to audit only some users in ApexSQLAudit?

2009-11-19T13:32:00.045-05:00

DESCRIPTION
This article discusses how to audit only chosen users with ApexSQL's Audit

SOLUTION
This is possible through changing the Trigger Template. To access the Trigger Template, click on the Template Editor button found on the Outlook Bar Auditing section:

This will start Template Editor:

Next, you should find the part where trigger for INSERT command is created:

'==================================================
'INSERT INSERT INSERT INSERT
'==================================================
caption = "Create Insert Trigger " & "[" & objTable.Owner & "].[" & StartTriggerNameInsert & objTable.Name & "]" & _ ">" for Table " & TableFullName%}
IF OBJECT_ID('{%Audit.Print replace("[" & objTable.Owner & "].[" & StartTriggerNameInsert & objTable.Name & "]", "'", "''") %}','TR') IS NOT NULL
BEGIN
DROP TRIGGER {%Audit.Print "[" & objTable.Owner & "].[" & StartTriggerNameInsert & objTable.Name & "]" %}
PRINT '{% Audit.Print "Trigger Dropped: " & StartTriggerNameInsert & Replace(objTable.Name,"'","''")%}'
END
GO
-- {%Audit.Print caption%}
Print '{%Audit.Print Replace(caption, "'", "''")%}'
go
CREATE TRIGGER {%Audit.Print "[" & objTable.Owner & "].[" & StartTriggerNameInsert & objTable.Name & "]" %}
ON {%Audit.Print TableFullName%}
FOR INSERT
NOT FOR REPLICATION
As
-- "SQLAUDIT GENERATED - DO NOT REMOVE"
-- -------------------------------------------------------------------------------------------
-- Legal: {%Audit.Print Audit.Legal%}
-- Description: INSERT TRIGGER for Table: {%Audit.Print TableFullName%}
-- Author: {%Audit.Print Audit.Author%}
-- Date: {%Audit.Print Now%}
-- -------------------------------------------------------------------------------------------
BEGIN

there you should add following:

IF (SUSER_SNAME() <> N'ComputerName\UserName1') AND (SUSER_NAME() <> N'ComputerName\UserName2') RETURN

Where ComputerName\UserName1 and ComputerName\UserName2 are the user names you want to include in auditing in case they use Windows Authentication on connecting to your server or UserNam1 and UserName2 in case they use SQL Authentication.

These steps you need to repeat for UPDATE (found below this)
'==================================================
' UPDATE UPDATE UPDATE UPDATE UPDATE
'==================================================

and DELETE trigger template.
'==================================================
' DELETE DELETE DELETE DELETE
'==================================================

with the same command:

IF (SUSER_SNAME() <> N'ComputerName\UserName1') AND (SUSER_NAME() <> N'ComputerName\UserName2') RETURN

Then you need to recreate triggers on your tables. First, check tables and columns you want to audit, and then create triggers by clicking on the Create Triggers button:

Script will be built. You just need to execute it:

This will recreate all triggers, and now only users with given names will be audited.

SEE ALSO
How to audit user names in ASP.Net application
How to update ApexSQL Audit without losing custom changes in the architecture
Schedule Audit Report generation
How to Delete Old Data in Audit tables

AUTHOR
Milic Vuletic

LAST REVIEW DATE
19 November 2009

How to integrate ApexSQL Log API components into custom installer

2009-11-19T09:01:00.008-05:00

DESCRIPTION
This article describes solutions for integrating ApexSQL Log API components into custom installer

SOLUTION
ApexSQL Log API components can be integrated into custom installer in two ways. The first one is running original ApexSQL Log API setup with the INNO setup switches for silent mode installation. The second solution is to create simple .NET application which will copy all required files, register them, create extended procedures on a server and check the activation status.
Let’s start with the first solution: running ApexSQL Log API installer from your installer:
To use the silent mode installation, use ApexSQL Log API setup with the following switches:
/VERYSILENT – this suppresses all installation wizard dialogs
/SUPPRESSMSGBOXES – this suppresses all messages from the installer
/LOADINF="filename" – this will load the previously saved installer settings (such as the installation directory, shortcuts and so forth…)
/SAVEINF="filename" – this will save all of your choices during an “ideal” installation (these choices will then be used in LOADINF switch)

1. Start ApexSQL Log API installer with SAVEINF switch from the command prompt (e.g. ApexSQLLogApi.exe /saveinf="logapi.inf"), make all necessary choices and finish the installation. This will save all your preferences to the .inf file In the following format:
[Setup]
Lang=eng
Dir=C:\Program Files\ApexSQL\ApexSQLLogApi2008
Group=ApexSQL\ApexSQL Log API 2008
NoIcons=0
SetupType=full
Components=client_side,server_side
Tasks=

2. Add this call to the custom setup step to run original ApexSQL Log API installer with the INF file created on previous step and the following switches:

ApexSQLLogApi.exe /VERYSILENT /SUPPRESSMSGBOXES /LOADINF =" logapi.inf"

The second solution is more complicated and consists of the below steps. The example of this solution can be found here

1. Create new Console Application project in Visual Studio and add a reference to the ApexSQL.Log.Api.dll in it

2. Add a reference to the ApexSql.Log namespace from within the code file:

using ApexSql.Log;

3. Depending on how server-side installation will be performed add verification on the number of arguments passed to the console application from the customer setup. Let’s assume that application is receiving just server name

4. Configure engine by calling Config.ConfigureLogging

        static void ConfigureEngine()
        {
            //  Engine configuration has to be done before first reference to Engine class.
            //  Setup logging file name and folder.
            Config.LoggingConfiguration loggingConfig = new Config.LoggingConfiguration();
            loggingConfig.loggingEnabled = true;
            loggingConfig.logFileName = String.Format("ApexSqlLogApiInstallation.{0}.log", DateTime.Now.ToString("yyyyMMddHHmmss"));
            Config.ConfigureLogging(loggingConfig);
        }

5. Add verification on server-side components state on server and perform appropriate actions according to the current their state:

        static bool CheckVersionInformation(Database db)
        {
            ServerSideComponentsManager manager = Engine.CreateServerSideComponentsManager(db);

            ServerSideComponentsState state = manager.ComponentsState;
            switch (state)
            {
                case ServerSideComponentsState.NotInstalled:
                    {
                        Console.WriteLine("Server-side components are not installed. Installing server-side components to server {0}...",
                            db.Properties.server);
                        manager.InstallComponents();
                        break;
                    }
                case ServerSideComponentsState.IncompleteInstallation:
                    {
                        Console.WriteLine("Server-side components are not correctly installed. Uninstalling and then installing server-side components on server {0}...",
                            db.Properties.server);

                        try
                        {
                            manager.UninstallComponents();
                        }
                        catch (System.Exception e)
                        {
                            Console.WriteLine("Exception occurred during uninstallation of server-side components: {0}", e.Message);
                        }

                        manager.InstallComponents();
                        break;
                    }
                case ServerSideComponentsState.EarlierVersion:
                    {
                        Console.WriteLine("Installed server-side components are out of date (version {0}). Updating components on server {1}...",
                            manager.ComponentsVersion, db.Properties.server);
                        manager.InstallComponents();
                        break;
                    }
                case ServerSideComponentsState.LaterVersion:
                    {
                        Console.WriteLine("Installed server-side components on server {0} are of later version ({1}). Please update your ApexSQL Log API version.",
                            db.Properties.server, manager.ComponentsVersion);
                        return false;
                    }
            }

            if (manager.ComponentsState == ServerSideComponentsState.CompatibleVersion)
            {
                Console.WriteLine("Installed server-side components on server {0} are compatible with this version of ApexSQL Log API.", db.Properties.server);
                return true;
            }
            else
            {
                Console.WriteLine("Installed server-side components are still not up to date. Please check application log file for detailed errors.");
                return false;
            }
        }

6. Compile the project

7. Add server-side component files to the custom installer:

ApexSqlLog2008XprocsIA64.dll
ApexSqlLog2008Xprocsx64.dll
ApexSqlLog2008Xprocsx86.dll
ApexSqlLog2008Activation.exe
ApexSqlLog2008ConnectionMonitorIA64.exe
ApexSqlLog2008ConnectionMonitorx64.exe
ApexSqlLog2008ConnectionMonitorx86.exe
ApexSqlLog2008ServerHelperIA64.exe
ApexSqlLog2008ServerHelperx64.exe
ApexSqlLog2008ServerHelperx86.exe
ApexSqlLogApi2008Activation.exe
ApexSqlLog2008ServerHelperIA64.sys
ApexSqlLog2008ServerHelperx64.sys
ApexSqlLog2008ServerHelperx86.sys

8. Add vcredist_x86.exe, which is part of the ApexSQL Log API setup to the custom setup

9. Add ApexSQL.Log.Api.dll to the custom setup

10. Add just compiled application to the custom setup

11. Extract and run vcredist_x86.exe from the setup

12. Extract compiled application, ApexSQL.Log.Api.dll and server-side components to
some temp location from the custom setup and run compiled application from here with the server specified as parameter

13. Server-side components should be installed on server passed to it as argument.

14. Example of the installation script which is used for ApexSQL Log API installation and created in the INNO you can find here

AUTHOR
Dmitriy Dyubchenko

LAST REVIEW DATE
26 November 2009

How to enable execution of user code in the .NET Framework

2009-09-24T07:33:00.005-04:00

DESCRIPTION
This article will show you how to enable execution of user code in the .NET Framework and avoid message “Execution of user code in the .NET Framework is disabled. Enable ‘clr enabled’ configuration option” in ApexSQL products.

SOLUTION
In Microsoft SQL Server 2005.
1. Explore "Microsoft SQL Server 2005/Configuration Tools/SQL Server Surface Area Configuration" in your Start menu.
2. Select "Surface Area Configuration for Features"
3. You will find "CLR Integration" option, activate it and save.

Another way to enable this feature is with SQL (using SQL Server Management Studio).

sp_configure 'show advanced options', 1;
GO

RECONFIGURE;
GO

sp_configure 'clr enabled', 1;
GO

RECONFIGURE;
GO

The error message will no longer appear in ApexSQL products.

SEE ALSO
General FAQs

AUTHOR
Evgeniy Spashko

LAST REVIEW DATE
24 Sep 2009

What files should be backed up to copy settings of one ApexSQL Edit 2008.06 installation to another location?

2009-08-20T08:46:00.009-04:00

DESCRIPTION
This article describes what files should be backed up if you want to copy settings of your ApexSQL Edit installation to another computer.

SOLUTION
You need to back up files and directories listed below if you want to copy your ApexSQL Edit settings:

   Note: we use the following variable names in the directory listing below:
      $InstallFolder$ variable should be replaced by your installation folder, for example C:\Program Files\ApexSQL\ApexSQL Edit,
      $MyDocuments$ variable should be replaced by your Documents and Settings folder, for example C:\Documents and Settings\Administrator\My Documents\ for Windows XP or \Users\$UserName$\Documents\ApexSQL\ApexSQLEdit2008 for Windows Vista,
      $UserAppData$ variable should be replaced by your Application Data folder, for example C:\Documents and Settings\Administrator\Local Settings\Application Data\ApexSQL\ApexSQLEdit for Windows XP or \Users\$UserName$\AppData\Local\ApexSQL\ApexSQLEdit for Windows Vista:

• $InstallFolder$\Report Templates the folder that stores your report definitions,
• $InstallFolder$\SQL Templates the folder stores SQL template files which appear as new commands under main menu File (default ones are New Stored Procedure and New User Defined Function commands),
• $InstallFolder$\edit.project the file that stores your startup default project settings,
• $InstallFolder$\BlankQuery.xml the default blank (new) query file,
• $InstallFolder$\Favorites.xml this file stores the list of selected favorite Schema Explorer nodes (objects) which appear under reserved schema folder named “Favorites”,
• $InstallFolder$\Options.xml this file stores information about ApexSQL Edit options and configuration (including Source Control connections and setup),
• $InstallFolder$\Queries.xml the file stores user defined queries,
• $InstallFolder$\Replacements.xml this file stores definitions of auto replacements,
• $InstallFolder$\Layouts.xml this file stores information about user interface configuration such as window sizes, positions, panel setup, etc; please note that this file shouldn’t be transferred to the new installation if the destination operating system has lower desktop resolution as it may cause some windows to become inaccessible or hidden,
• $MyDocuments$\ApexSQL\ApexSQLEdit2008 the folder is a default location for user files (projects, workspaces etc),
• $MyDocuments$\ApexSQL\ApexSQLEdit2008\Snippets\My Snippets the folder is a default suggested location of application and user defined Snippets,
Note: It is possible to store custom Snippets in subfolders of the $MyDocuments$\ApexSQL\ApexSQLEdit2008\Snippets folder. In such a case all subfolders created by a user should be also backed up.
• $MyDocuments$\ApexSQL\ApexSQLEdit2008\Templates\My Templates the folder is a default suggested location of application and user defined Templates,
Note: It is possible to store custom Templates in subfolders of the $MyDocuments$\ApexSQL\ApexSQLEdit2008\Templates folder. In such a case all subfolders created by a user should be also backed up.
• $UserAppData$\ApexSQL\ApexSQLEdit\Backup the application auto-backup history folder,
• $UserAppData$\ApexSQL\ApexSQLEdit\Settings the folder stores customization files for quick info, aliases, tab colors, macros, and more.

After you copy/backup up all necessary directories and files, you should paste/restore them into your corresponding destination folder(s).
Note: Remember that ApexSQL Edit application should not be run when you back up and restore the files/directories listed above.

AUTHOR
Anna Lesniak

LAST REVIEW DATE
20 August 2009

Undoing schema changes (Drop Object)

2009-08-14T07:29:00.004-04:00

DESCRIPTION
This article describes how to undoing schema changes occurred by DROP [Object] operation.

SOLUTION
1. Open ApexSQL Recover and point it to your SQL Server:

2. Select ‘Recover lost object due to a Drop [Object] operation’ recovery option

3. Specify database for recovery:

4. Select ‘several sources are available for data recovery’ option

5. Specify data sources:

6. Specify path for the recovery script and generate it:

7. Open generated recovery script and review that it contains required data:

8. Run generate script versus your database to recover lost objects

SEE ALSO
Recover from rogue delete statement with no backup, or without having to do a full restore
Recover from a rogue truncate table statement with no backup, or without having to do a full restore
Recover from a rogue drop table statement with no backup, or without having to do a full restore
Recover single table data from a database backup "row level recovery", without having to do a full restore
Recovering a file from sharepoint database
Recovering corrupted database

AUTHOR
Dmitriy Dyubchenko

LAST REVIEW DATE
14 August 2009

Recovering corrupted database

2009-08-14T07:11:00.004-04:00

DESCRIPTION
This article describes how to recover corrupted database when detached MDF file and database backup are available only. Online database is completely corrupted at the same time.
Note: ApexSQL Recover supports recovery of BLOB values from database files (online, detached and db backups) only. Recovery of BLOB values from transaction log files is not supported yet.

SOLUTION
1. Open ApexSQL Recover and point it to your SQL Server:

2. Select ‘Recover from corrupted database or detached mdf’ recovery option

3. Specify that there is not older online database is available:

4. Add detached MDF database file and its backup for recovery:

5. Specify tables for recovery:

6. Specify path for the recovery script and generate it:

7. Open generated recovery script and review that it contains required data:

SEE ALSO
Recover from rogue delete statement with no backup, or without having to do a full restore
Recover from a rogue truncate table statement with no backup, or without having to do a full restore
Recover from a rogue drop table statement with no backup, or without having to do a full restore
Recover single table data from a database backup "row level recovery", without having to do a full restore
Recovering a file from sharepoint database
Undoing schema changes (Drop Object)

AUTHOR
Dmitriy Dyubchenko

LAST REVIEW DATE
14 August 2009

Recovering a file from sharepoint database

2009-08-14T06:52:00.005-04:00

DESCRIPTION
This article describes how to recover deleted BLOB data from the online Sharepoint database as files.
Note: ApexSQL Recover supports recovery of BLOB values from database files (online, detached and db backups) only. Recovery of BLOB values from transaction log files is not supported yet.

SOLUTION
1. Please make sure that you detached the db and backed up the raw MDF and LDF files. Doing full backup won’t do the trick as it will just backup pages in use and active part of transaction log whereas we need both deallocated pages and the entire transaction log to maximize chances of good recovery.

2. Once you have backed up the files please attach them as another database, put it into readonly mode. If this is not possible, than please put original database to readonly mode, the less post-incident activities is performed on database the more possibility for successful data recovery

3. Open ApexSQL Recover and point it to your SQL Server:

4. Select ‘Recover BLOB data as files’ recovery option

5. Select ‘Online Database’ option:

6. Specify database for recovery:

7. Select ‘Yes’ for ‘Where these BLOB data lost due to a DELETE operation?’ question:

8. Specify folder for the BLOB’s files:

9. Run Recovery process:

10. Open Output directory and check generated files for BLOB data.

SEE ALSO
Recover from rogue delete statement with no backup, or without having to do a full restore
Recover from a rogue truncate table statement with no backup, or without having to do a full restore
Recover from a rogue drop table statement with no backup, or without having to do a full restore
Recover single table data from a database backup "row level recovery", without having to do a full restore
Recovering corrupted database
Undoing schema changes (Drop Object)

AUTHOR
Dmitriy Dyubchenko

LAST REVIEW DATE
14 August 2009

Recover single table data from a database backup "row level recovery", without having to do a full restore

2009-08-13T07:45:00.006-04:00

DESCRIPTION
This article describes how to recover table data lost occurred when there is no possibility to create a full database restore and just full database backup is available.
Note: ApexSQL Recover supports recovery of BLOB values from database files (online, detached and db backups) only. Recovery of BLOB values from transaction log files is not supported yet.

SOLUTION
1. Please make full database backup and copy it to the machine where ApexSQL Recover is installed.

2. Open ApexSQL Recover and point it to your SQL Server:

3. Select ‘Recovery table data from a database backup’ recovery option

4. Specify database backup for audit:

5. Select tables for data recovery:

6. Specify path for the recovery script and generate it:

7. Open generated recovery script and review that it contains required data:

8. Run it versus your database:

SEE ALSO
Recover from rogue delete statement with no backup, or without having to do a full restore
Recover from a rogue truncate table statement with no backup, or without having to do a full restore
Recover from a rogue drop table statement with no backup, or without having to do a full restore
Recovering a file from sharepoint database
Recovering corrupted database
Undoing schema changes (Drop Object)

AUTHOR
Dmitriy Dyubchenko

LAST REVIEW DATE
13 August 2009

Recover from a rogue drop table statement with no backup, or without having to do a full restore

2009-08-13T07:38:00.007-04:00

DESCRIPTION
This article describes how to recover data lost occurred by the drop table operation, when there is no database or transaction log backups available and no possibility to create a full database restore.
Note: ApexSQL Recover supports recovery of BLOB values from database files (online, detached and db backups) only. Recovery of BLOB values from transaction log files is not supported yet.

SOLUTION
1. Please make sure that you detached the db and backed up the raw MDF and LDF files. Doing full backup won’t do the trick as it will just backup pages in use and active part of transaction log whereas we need both deallocated pages and the entire transaction log to maximize chances of good recovery.

2. Once you have backed up the files please attach them as another database, put it into readonly mode. If this is not possible, than please put original database to readonly mode, the less post-incident activities is performed on database the more possibility for successful data recovery

3. Open ApexSQL Recover and point it to your SQL Server:

4. Select ‘Recovery lost data due to Drop operation’ recovery option

5. Specify database for recovery:

6. Select ‘several sources are available for data recovery’ option

7. Specify data sources:

8. Specify path for the recovery script and generate it:

9. Open generated recovery script and review that it contains required data:

10. Run it versus your database

SEE ALSO
Recover from rogue delete statement with no backup, or without having to do a full restore
Recover from a rogue truncate table statement with no backup, or without having to do a full restore
Recover single table data from a database backup "row level recovery", without having to do a full restore
Recovering a file from sharepoint database
Recovering corrupted database
Undoing schema changes (Drop Object)

AUTHOR
Dmitriy Dyubchenko

LAST REVIEW DATE
13 August 2009

Recover from a rogue truncate table statement with no backup, or without having to do a full restore

2009-08-13T07:30:00.006-04:00

DESCRIPTION
This article describes how to recover data lost occurred by the truncate operation, when there is no database or transaction log backups available and no possibility to create a full database restore.
Note: ApexSQL Recover supports recovery of BLOB values from database files (online, detached and db backups) only. Recovery of BLOB values from transaction log files is not supported yet.

SOLUTION
1. Please make sure that you detached the db and backed up the raw MDF and LDF files. Doing full backup won’t do the trick as it will just backup pages in use and active part of transaction log whereas we need both deallocated pages and the entire transaction log to maximize chances of good recovery.

2. Once you have backed up the files please attach them as another database, put it into readonly mode. If this is not possible, than please put original database to readonly mode, the less post-incident activities is performed on database the more possibility for successful data recovery

3. Open ApexSQL Recover and point it to your SQL Server:

4. Select ‘Recovery lost data due to Truncate operation’ recovery option

5. Specify database for recovery:

6. Select table(s) for which data lost has occurred:

7. Specify path for the recovery script and generate it:

8. Open generated recovery script and review that it contains required data:

9. Run it versus your database

SEE ALSO
Recover from rogue delete statement with no backup, or without having to do a full restore
Recover from a rogue drop table statement with no backup, or without having to do a full restore
Recover single table data from a database backup "row level recovery", without having to do a full restore
Recovering a file from sharepoint database
Recovering corrupted database
Undoing schema changes (Drop Object)

AUTHOR
Dmitriy Dyubchenko

LAST REVIEW DATE
13 August 2009

Recover from rogue delete statement with no backup, or without having to do a full restore

2009-08-12T10:18:00.010-04:00

DESCRIPTION
This article describes how to recover data lost occurred by the delete operation, when there is no database or transaction log backups available and no possibility to create a full database restore
Note: ApexSQL Recover supports recovery of BLOB values from database files (online, detached and db backups) only. Recovery of BLOB values from transaction log files is not supported yet.

SOLUTION
1. Please make sure that you detached the db and backed up the raw MDF and LDF files. Doing full backup won’t do the trick as it will just backup pages in use and active part of transaction log whereas we need both deallocated pages and the entire transaction log to maximize chances of good recovery.

2. Once you have backed up the files please attach them as another database, put it into readonly mode. If this is not possible, than please put original database to readonly mode, the less post-incident activities is performed on database the more possibility for successful data recovery

3. Open ApexSQL Recover and point it to your SQL Server:

4. Select ‘Recovery lost data due to Delete operation’ recovery option

5. Specify database for recovery:

6. Select ‘several sources are available for data recovery’ option

7. Specify data sources:

8. And select table(s) for which data lost has occurred:

9. Specify path for the recovery script and generate it:

10. Open generated recovery script and review that it contains required data:

11. Run it versus your database

SEE ALSO
Recover from a rogue truncate table statement with no backup, or without having to do a full restore
Recover from a rogue drop table statement with no backup, or without having to do a full restore
Recover single table data from a database backup "row level recovery", without having to do a full restore
Recovering a file from sharepoint database
Recovering corrupted database
Undoing schema changes (Drop Object)

AUTHOR
Dmitriy Dyubchenko

LAST REVIEW DATE
13 August 2009

What are the required permissions to document jobs?

2009-08-10T05:08:00.005-04:00

DESCRIPTION
The minimum permission requirement for jobs documenting are described in this article.

SOLUTION
Jobs are the part of SQL Server Agent and are accessed in different way comparing to regular database objects. Account which is used for jobs documenting should be granted the following permissions:
1. Login used to connect to SQL Server must be part of sysadmin server role. Here is the shot for that. In any other case no jobs will be documented:

2.Also the user related to this login must have db_creator role set on a database that is selected. Nothing specific needs to be set for msdb database.

AUTHOR
Dmitriy Dyubchenko

LAST REVIEW DATE
10 August 2009

How to migrate from ApexSQL Edit 2008.05 to 2008.06 if you have a database mapped to a Source Control system using the CUSTOM mapping pattern?

2009-08-07T16:14:00.028-04:00

DESCRIPTION
This article describes how to migrate from ApexSQL Edit 2008.05 to 2008.06 or higher if you have a database mapped to a Source Control system using the custom mapping pattern.

SOLUTION
A mapping pattern defines a way of scripting database objects to Source Control: it includes file name templates and subprojects for each object type.

Let’s assume that you have mapped a database to a Source Control system using the following settings in ApexSQL Edit 2008.05:

   a) Scripts for each database object type were stored in a separate Source Control project, like displayed below:

   b) Script file names consist of the schema name, object name and ‘sql’ extension (for example dbo.Table1.sql).

Follow the procedure described below to map your database to the existing Source Control project defined in ApexSQL Edit 2008.05 using ApexSQL Edit 2008.06 (Microsoft Visual SourceSafe 2005 is used as an example of the Source Control system):

   1. Install ApexSQL Edit 2008.06 in a separate folder leaving ApexSQL Edit 2008.05 in its old folder.
   2. After you have started ApexSQL Edit 2008.06 your databases appear not mapped to a Source Control system even if they were mapped in the previous ApexSQL Edit version.
   3. Right click the database that is to be mapped to the existing Source Control project created using the previous version of ApexSQL Edit and select the Set up Source Control command from the Source Control menu.

   4. Select the Microsoft Visual SourceSafe from the available Native Source Control systems and click the Next button.
   5. Enter the Source Control Login information as displayed below:

Remember to select the same Source Control database as it was used by the ApexSQL Edit 2008.05 version, the same Source Control project and the same working folder.
You can click the Test button to verify if you can access your Source Control database/project using the parameters entered on the Source Control Login tab.

   6. Then click the Advanced button to display additional Source Control Wizard steps and click Next.

Click in the Subfolder name edit box and change the default subfolder names to the ones you defined in ApexSQL Edit 2008.05 (for example delete the default text “Functions” and enter the “Funcs”, then change the subfolder names for other database object types).

Note: If a Central database was used in ApexSQL Edit 2008.05, then:
   a) The first user who is migrating to the newer version should export all current settings defined in the Advanced | Configure Mappings tab to an xml file using the Export… button.
   b) Each next user who is migrating to the newer application version should import settings exported by the first user using the Import button.

After you have clicked the Next button ApexSQL Edit 2008.06 automatically maps database objects stored in a database to script files stored in a Source Control project based on the scripts file names.

Click the Finish button to complete the Source Control Wizard and the migration procedure. Your database and database’s objects are shown now as mapped to a Source Control system.

SEE ALSO
How to migrate from ApexSQL Edit 2008.05 to 2008.06 if you have a database mapped to a Source Control using the IMPLICIT mapping pattern?

AUTHOR
Anna Lesniak

LAST REVIEW DATE
07 August 2009

How to migrate from ApexSQL Edit 2008.05 to 2008.06 if you have a database mapped to a Source Control using the IMPLICIT mapping pattern?

2009-07-24T13:08:00.028-04:00

DESCRIPTION
This article describes how to migrate from ApexSQL Edit 2008.05 to 2008.06 or higher if you have a database mapped to a Source Control system using the implicit mapping pattern.

SOLUTION
The implicit mapping pattern is used by default in ApexSQL Edit 2008.05 and means that:
   a) Scripts for database’s objects were stored in the same Source Control project,
   b) Script file names consist of the schema name, object name and ‘sql’ extension (for example dbo.Table1.sql).

Follow the procedure described below to map your database to the existing Source Control project defined in ApexSQL Edit 2008.05 using ApexSQL Edit 2008.06 (Microsoft Visual SourceSafe 2005 is used as an example of the Source Control system):
   1. Install ApexSQL Edit 2008.06 in a separate folder leaving ApexSQL Edit 2008.05 in its old folder.
   2. After you have started ApexSQL Edit 2008.06.0164 your databases are not mapped to a Source Control system even if they were mapped in the previous ApexSQL Edit version.
   3. Right click the database that is to be mapped to the existing Source Control project created using the previous version of ApexSQL Edit and select the Set up Source Control command from the Source Control menu.

   4. Select the Microsoft Visual SourceSafe from the available Native Source Control systems and click the Next button.
   5. Enter the Source Control Login information as displayed below:

Remember to select the same Source Control database as it was used by the ApexSQL Edit 2008.05 version, the same Source Control project and the same working folder.
You can click the Test button to verify if you can access your Source Control database/project using the parameters entered on the Source Control Login tab.

   6. Then click the Advanced button to display additional Source Control Wizard steps and click Next.

Important! Deselect all check boxes for the Subfolder column on the Configure Mappings tab and click the Next button.

Note: If a Central database was used in ApexSQL Edit 2008.05.0163, then:
    a) The first user who is migrating to the newer version should export all current settings defined in the Advanced | Configure Mappings tab to an xml file using the Export… button.
    b) Each next user who is migrating to the newer application version should import settings exported by the first user using the Import button.

After you have clicked the Next button ApexSQL Edit 2008.06.0164 automatically maps database objects stored in a database to script files stored in a Source Control project based on the scripts file names.

Click the Finish button to complete the Source Control Wizard and the migration procedure. Your database and database’s objects are shown now as mapped to a Source Control system.

SEE ALSO
How to migrate from ApexSQL Edit 2008.05 to 2008.06 if you have a database mapped to a Source Control system using the CUSTOM mapping pattern?
How can I define the Source Control parameters when I set up different Source Control systems using native drivers in the Source Control Wizard?
How to map a database to a Source Control system step by step?

AUTHOR
Anna Lesniak

LAST REVIEW DATE
24 July 2009

How to integrate an SQL Server Management Studio with ApexSQL tools

2009-07-15T16:42:00.008-04:00

DESCRIPTION
This article demonstrates how to integrate SQL Server Management Studio editor with ApexSQL tools

SOLUTION
Often, when it is required to load and open large SQL scripts produced in ApexSQL tools the ApexSQL Editor may not be the best solution for the job, because the ApexSQL built in editor is not designed to handle large files. For that purpose SQL Server Management Studio should be used.

Here as a showcase we will integrate SQL Server Management Studio to ApexSQL Diff but the similarly it can be integrated to ApexSQL Data Diff, ApexSQL Script and others.

* From the Main Menu select Tools | Options
* From the Options dialog select Output tab as shown in the image

* Select SQL Server Management Studio Version you want to use (here I used 2005 version)

* Click OK to confirm

You have successfully set the SQL Server Management Studio as your default SQL Server editor.

Now, ApexSQL Diff will open SQL Server Management Studio when 'Launch Synchronization Script Editor' option is used in the Synchronization Wizard.

AUTHOR
Dejan Batanjac

LAST REVIEW DATE
July 15 2009

Using BeyondCopare as default comparison differences viewer

2009-07-14T19:06:00.005-04:00

DESCRIPTION
This article shows how to integrate BeyondCompare differences viewer with ApexSQL Diff

SOLUTION
ApexSQL Diff is shipped with CompareIt, its default difference viewer that is used for identifying script differences during comparison. However, you can use virtually any other third-party difference viewer with ApexSQL Diff. You just need to provide such information as the full path to that executable and, if necessary, the appropriate command line arguments.

Here are the steps how to integrate BeyondCompare with ApexSQL Diff

1. Install BeyondCompare
2. Set BeyondCompare as your default External Difference Viewer
2.1 Open Tools | Options | Diff Viewer tab from the Main menu.
2.3 In the Executable field enter the path to the BeyondCompare executable on your computer (for example C:\Program Files\Beyond Compare 3\Bcompare.exe)
2.3 Optionally you may set BeyondCompare additional arguments (or just leave as it is)
2.4 Click OK

Now after the call the External Difference Viewer you can watch the script differences using BeyondCompare.

AUTHOR
Dejan Batanjac

LAST REVIEW DATE
July 15 2009

How to associate .SQL files with ApexSQL Edit?

2009-07-14T16:09:00.006-04:00

DESCRIPTION
This article demonstrates how to associate files with the extension .SQL to ApexSQL Edit.

SOLUTION
Every program that's installed on your computer is designed to open one or more particular file types, each of which is identified by a file name extension. If you have more than one program on your computer capable of opening a file type, then one program is set as the default.

How to set ApexSQL Edit opens .SQL type of files by default?

1. Right-click .SQL file and click Choose Program from the context menu.

Find ApexSQL Edit using the Browse button....

Select it and click OK.

From the Open With dialog select Always use the selected program to open this kind of file check box, and then click OK.

At the end ApexSQL Diff will be your default .SQL files editor.

If you may want to associate other file types with ApexSQL Edit such as .PRC, .XML, .XSD just follow the same procedure as shown above.

AUTHOR
Dejan Batanjac

LAST REVIEW DATE
July 14 2009

How can I reduce the size of my .CHM file?

2009-07-10T06:48:00.011-04:00

DESCRIPTION
This article describes how the size of the CHM document can be reduced depending on the selected options for documenting.

SOLUTION
ApexSQL Doc enables you to create feature rich documentation that includes a lot of stuff in the final output. There are a couple of features that stand out as culprits for large documentation size. Let’s review how options changes affect resulting document based on standard SQL Server 2005 database AdventureWorks.

1. The main option that affects the result file size is graphical dependencies: removing this option from the documenting reduces its size on 90%, option can be turned OFF (by default it is turned OFF) here:

2. Table of Contents options:

by default they are all set to ON and the three groups of the Table of Contents are created in the resulting document:

Leaving just one out of these options reduces the size of the document up to 5 %.

3. Two Miscellaneous options:

Show Sections with no Relevant Meta Data to Document option results in displaying the following unnecessary information in the documentation:

Show Nodes for Object Types that don't Exist in Documented Database option results in creating the stub pages with no relevant information

Turning these options off will help saving another 5% of the resulting document size

4. Another set of the options may significantly (30-50%) reduce the size of the resulting document but they also affect the document data quality:

Explicitly Parse Database for Improved Dependency accuracy: It will slow down the analyzing process but returns more dependencies information when the option is ON.
Include Data Definition Language (DDL) Script: adds SQL scripts for all objects to the resulting document:

Highlight Transact-SQL keywords: If this option is checked resulted DDL scripts will have SQL keywords highlighted

Include Documentation of Procedure/Function Result Sets: It will show complete info on what values are returned from function or procedure

As a summary: Depending on the number of graphical dependencies, colors, state of the specified above options, the size of the generated .chm file may be reduced up to 95%. In oour example a .chm file was reduced from 61.5 Mb to 1.3 Mb, but this also affected the quality of data representation in the final document. You need to decide what data is necessary in the document and what may be omitted.

AUTHOR
Dmitriy Dyubchenko

LAST REVIEW DATE
13 July 2009

Why ApexSQL Recover doesn't recover indexes, primary keys and identity for drop data recovery

2009-06-26T04:13:00.004-04:00

DESCRIPTION
When I try to recover data from a drop table operation, ApexSQL Recover does not generate code for the primary key and other indexes.

SOLUTION
When doing recovery data lost, the simplest form of table schema is recovered on purpose. No IDENTITY, NULL/NOT NULL flags, primary key, default values or indexes are created - just column names with its data types. This is done because recovery process is not always unambiguous and can lead to duplicated rows depending on the database state. If we were to recover full table structure (as we did originally) it could lead to conflicting INSERT operation and possible data loss at the level of script. On the other hand, since the full table structure is generally known to the users, anyway there is no real loss - after the recovery the table just needs to be manually updated to its proper structure.

AUTHOR
Dmitriy Dyubchenko

LAST REVIEW DATE
17 August 2009