LINKS
General
Apex SQL Audit
Apex SQL Clean
Apex SQL Code
Apex SQL Diff
Apex SQL Doc
Apex SQL Edit
Apex SQL Enforce
Apex SQL Log
Apex SQL Script
Knowledgebase Home
Apex SQL Audit
Apex SQL Clean
Apex SQL Code
Apex SQL Diff
Apex SQL Doc
Apex SQL Edit
Apex SQL Enforce
Apex SQL Log
Apex SQL Script
Knowledgebase Home
MOST RECENT
Using ApexSQL's Snapshot Utility for Synchronizing Remote DBs and more
How to synchronize data between databases with different settings
Mapping in ApexSQL Diff, Part 3: Columns
Mapping in ApexSQL Diff, Part 2: Tables
Mapping in ApexSQL Diff, Part 1: Schemas
SITE FEED
Support Forum
The fastest and most effective to get answers to your questions quickly. Click Here for more info.
FAQs 
Quick answers to common questions. Click Here for more info.
Troubleshooting
Known issues and basic troubleshooting techniques for problems or unexpected behaviors. Click Here for more info.
Knowledgebase
Technical tips, How-to articles, and other tutorials about ApexSQL Tools. Click Here for more info.
Online Documentation
All of our help files for download or convenient viewing online. Click Here for more info.
Videos
Watch product demos, training videos, or tutorials of our products' main features. We frequently upload new videos so check often for updates. Click Here for more info.
|
ApexSQL Knowledgebase Tips and How-to Articles for Apex SQL Tools Using ApexSQL's Snapshot Utility for Synchronizing Remote DBs and more This article discusses how you can use ApexSQL Snapshot Utility to synchronize remote databases. It also discusses other possible uses of the utility. What is a snapshot? A snapshot is a read-only file in a binary format that stores the complete information of a database's schema. It can be used as a data source in ApexSQL applications. In ApexSQL Diff, for example, it can be used in structure comparison. The generated synchronization script can then be applied to a database. Using Snapshots to Synch Remote Databases ApexSQL snapshots are especially useful when dealing with remote databases. A snapshot of a database can be created and easily shared among peers (e.g. through email). The recipient of the snapshot who has ApexSQL Diff can then use it as a data source. The snapshot can be compared with another snapshot or with another database. Upon synchronization, the generated script can be run on another database (remote or otherwise). Using Snapshots for Maintaining Database Versions A snapshot can also be used to "version-control" your database's schema. This can easily be done by capturing a snapshot of the database periodically. These snapshots can then be stored in a source control system--like an ordinary file. Old versions of the database schema can then be used to restore a database to certain point. With ApexSQL Diff for example, you can use a version of the snapshot and compare it with your live database. The generated synchronization script, when run, will synchronize both data source. Can I use the snapshots with ApexSQL's command line interface? Yes. Using ApexSQL Diff's command line, snapshots (as well as databases) can be used as data sources. Note: The command line interface of ApexSQL applications is usually used to automate or schedule procedures that are done in GUI. The ApexSQL Snapshot Utility Before, the only way to create ApexSQL snapshots was through ApexSQL Diff which had the functionality embedded to it. So to take advantage of the full benefits of snapshots, a user would first need to have ApexSQL Diff running on his machine. The ApexSQL Snapshot Utility was created to enable users to create snapshots without ApexSQL Diff. The utility is FREE and can be installed on multiple remote sites. Below are some of its uses (some of which are already mentioned above): 1. To synchronize two or more disconnected databases 2. To spread the changes applied to a development database's schema to number of client–side databases. For example, a client database may not be accessible remotely due to security restrictions 3. To capture and store a remote database schema as part of a database schema change event processing 4. To load a snapshot of a remote database schema into a source control system Creating a snapshot using the Snapshot Utility To create a snapshot, connect to a SQL Server using either Windows or SQL Server authentication, select the database you want to create a snapshot of, and specify the snapshot name and where you want to save it. Creating an ApexSQL snapshot in GUI mode  Creating an ApexSQL Snapshot in CLI mode  ApexSQL Snapshot Utility command line switches  More Information Download ApexSQL Snapshot Utility AUTHOR Irene Sanford LAST REVIEW DATE 10 April 2008 Labels: Apex SQL Diff ...How to synchronize data between databases with different settings DESCRIPTION How to synchronize data between databases with different settings The behaviour of DATETIME or SMALLDATETIME type of data can be influenced by client, server, and/or Operating System settings. This KB article describes how to use ApexSQL Diff in situations where these settings must be considered. SOLUTION To illustrate, we use three databases located in three different countries. The goal is to synchronize the data between any two of these databases. The main database is hosted on a SQL Server instance with US English settings; the other two databases with France and Germany settings. Below script creates three databases: General, French, and German. Each database contains one table named t. The table t contains only one DATETIME column named TheDate. CREATE DATABASE GENERAL COLLATE LATIN1_GENERAL_CI_AI GO CREATE DATABASE FRENCH COLLATE FRENCH_CS_AI GO CREATE DATABASE GERMAN COLLATE GERMAN_PHONEBOOK_CS_AI GO USE GENERAL CREATE TABLE T ( THEDATE DATETIME ) GO USE FRENCH CREATE TABLE T ( THEDATE DATETIME ) GO USE GERMAN CREATE TABLE T ( THEDATE DATETIME ) GO Common problems with temporal data when working in international environments USA, France, and Germany all use a different date format. To illustrate what happens when data is inserted to above databases, we use the SET LANGUAGE command. To insert data to General database using the French date format DD/MM/YYYY, we execute below script: USE GENERAL SET LANGUAGE ENGLISH INSERT INTO T VALUES('23/08/2007') CHANGED LANGUAGE SETTING TO US_ENGLISH. MSG 242, LEVEL 16, STATE 3, LINE 3 THE CONVERSION OF A CHAR DATA TYPE TO A DATETIME DATA TYPE RESULTED IN AN OUT-OF-RANGE DATETIME VALUE. THE STATEMENT HAS BEEN TERMINATED. Due to the difference in language settings, insertion fails. SQL Server cannot resolve the string '23/08/2007' to a valid date format. To insert the same data to the German database, we execute the following script: USE GERMAN SET LANGUAGE GERMAN INSERT INTO T VALUES('23/08/2007') DIE SPRACHENEINSTELLUNG WURDE AUF DEUTSCH GEäNDERT. (1 ROW(S) AFFECTED) The data is inserted successfully. We do the same thing with the French database using below script: USE FRENCH SET LANGUAGE FRENCH INSERT INTO T VALUES('23/08/2007') LE PARAMèTRE DE LANGUE EST PASSé à FRANçAIS. (1 ROW(S) AFFECTED) Insertion to the French database is successful as well. The results would be the same if we attempted to insert data with the German date format DD.MM.YYYY to our three sample databases; insertion would fail on the General database and it'd be successful on the other two. On the otherhand, if we attempt to insert data that's in US date format MM/DD/YYYY to all three database, only the insertion to the General database would be successful. The two other INSERT statements cannot be committed successfully and would raise a conversion error. Using SQL Server's CONVERT statement to apply the correct date format style before performing the insertion resolves these insertion errors. In the next section, we discuss how to synchronize temporal data in international environments that are similar to our example by using ApexSQL Diff AND without the additional "conversion" step. Using ApexSQL Diff to synchronize temporal data when working in international environments Example 1: In this example, the French database has one row that's not in the General database. To synchronize the General database with the French database, ApexSQL Diff generates below synchronization script: USE GENERAL SET LANGUAGE ENGLISH SET IDENTITY_INSERT [DBO].[T] ON INSERT INTO [DBO].[T] ([ID], [THEDATE]) VALUES (1, '20070823 00:00:00.000') SET IDENTITY_INSERT [DBO].[T] OFF CHANGED LANGUAGE SETTING TO US_ENGLISH. (1 ROW(S) AFFECTED) Example 2: In this example, the German database has one row that's not in the French database. To synchronize the French database with the German database, ApexSQL Diff generates below synchronization script USE FRENCH SET LANGUAGE FRENCH SET IDENTITY_INSERT [DBO].[T] ON INSERT INTO [DBO].[T] ([ID], [THEDATE]) VALUES (1, '20070823 00:00:00.000') SET IDENTITY_INSERT [DBO].[T] OFF LE PARAMèTRE DE LANGUE EST PASSé à FRANçAIS. (1 ROW(S) AFFECTED) Example 3: In this example, the General database has one row that's not in the German database. To synchronize the German database with the General database, ApexSQL Diff generates below synchronization script USE GERMAN SET LANGUAGE GERMAN SET IDENTITY_INSERT [DBO].[T] ON INSERT INTO [DBO].[T] ([ID], [THEDATE]) VALUES (1, '20070823 00:00:00.000') SET IDENTITY_INSERT [DBO].[T] OFF DIE SPRACHENEINSTELLUNG WURDE AUF DEUTSCH GEäNDERT. (1 ROW(S) AFFECTED) All of the above scripts complete successfully. By default, ApexSQL Diff uses language-neutral date format settings. This default can be modified by clicking on the Synchronization Wizard button in the Outlook bar then choosing Configuration item from the Graphical Treeview:  The "Apply Date Format" option by default uses the unseparated date format:  The most commonly used formats are also readily available:  To add a format that's not in the list or to use one that already is, check "Apply Date Format", select (or enter) the format, and click the Finish button. The selected format will then be used by ApexSQL Diff on all (SMALL)DATETIME data type columns encountered during the scripting process. For example, suppose we use the US date format:  The script output would be: SET IDENTITY_INSERT [DBO].[T] ON INSERT INTO [DBO].[T] ([ID], [THEDATE]) VALUES (1, '08/23/2007 00:00:00.000') SET IDENTITY_INSERT [DBO].[T] OFF AUTHOR Frank Kirkland LAST REVIEW DATE 07 September 2007 Labels: Apex SQL Diff ...Mapping in ApexSQL Diff, Part 3: Columns DESCRIPTION This is the third and last installment in the three-article KB series discussing ApexSQL Diff's mapping ability. With ApexSQL Diff, you can map users/schemas, tables, and columns. Here, we discuss how to map columns. What does "mapping columns" mean? As mentioned in Mapping Schemas, ApexSQL Diff runs in two different modes: Structure mode compares and syncs database structures and Data mode compares and syncs data. Mapping columns applies only to Data mode. By default, ApexSQL Diff automatically maps columns of the same name in tables of the same name owned by schemas having the same name. That is, when you have a column named "Col1" in a table named "Table" in a schema named "Schema1" in both the source and destination of your project, these columns will be automatically mapped by ApexSQL Diff. When the schemas in both source and destination differ in their names, ApexSQL Diff will not automatically map them. This is the case even when the object names in the schemas are all equal; the tables will still be unmapped. To address this, ApexSQL Diff allows table mapping. The same logic applies for columns. Even when schema and table names are equal, when column names are not, the columns won't automatically be mapped. Mapping columns enable you to compare objects that belong to the same or different schemas and tables. Mapping columns To reproduce the situation, let's issue the following batch: USE MASTER CREATE DATABASE BOSTON GO USE BOSTON GO CREATE SCHEMA BOSTON_USERS AUTHORIZATION DBO GO IF OBJECT_ID('Boston_Users.Employees') > 0 DROP TABLE BOSTON_USERS.EMPLOYEES CREATE TABLE [BOSTON_USERS].[EMPLOYEES]( [EMPLOYEEID_Z] [INT] IDENTITY(1,1) NOT NULL, [LASTNAME_Z] [NVARCHAR](20) COLLATE LATIN1_GENERAL_CI_AS NOT NULL, [FIRSTNAME_Z] [NVARCHAR](10) COLLATE LATIN1_GENERAL_CI_AS NOT NULL, [TITLE_Z] [NVARCHAR](30) COLLATE LATIN1_GENERAL_CI_AS NULL, [TITLEOFCOURTESY_Z] [NVARCHAR](25) COLLATE LATIN1_GENERAL_CI_AS NULL, [BIRTHDATE] [DATETIME] NULL, [HIREDATE] [DATETIME] NULL, [ADDRESS] [NVARCHAR](60) COLLATE LATIN1_GENERAL_CI_AS NULL, [CITY] [NVARCHAR](15) COLLATE LATIN1_GENERAL_CI_AS NULL, [REGION] [NVARCHAR](15) COLLATE LATIN1_GENERAL_CI_AS NULL, [POSTALCODE] [NVARCHAR](10) COLLATE LATIN1_GENERAL_CI_AS NULL, [COUNTRY] [NVARCHAR](15) COLLATE LATIN1_GENERAL_CI_AS NULL, [HOMEPHONE] [NVARCHAR](24) COLLATE LATIN1_GENERAL_CI_AS NULL, [EXTENSION] [NVARCHAR](4) COLLATE LATIN1_GENERAL_CI_AS NULL, [PHOTO] [IMAGE] NULL, [NOTES] [NTEXT] COLLATE LATIN1_GENERAL_CI_AS NULL, [REPORTSTO] [INT] NULL, [PHOTOPATH] [NVARCHAR](255) COLLATE LATIN1_GENERAL_CI_AS NULL, CONSTRAINT [PK_EMPLOYEES] PRIMARY KEY CLUSTERED ( [EMPLOYEEID_Z] ASC )WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY] GO ALTER TABLE [BOSTON_USERS].[EMPLOYEES] WITH NOCHECK ADD CONSTRAINT [FK_EMPLOYEES_EMPLOYEES] FOREIGN KEY([REPORTSTO]) REFERENCES [BOSTON_USERS].[EMPLOYEES] ([EMPLOYEEID_Z]) GO ALTER TABLE [BOSTON_USERS].[EMPLOYEES] CHECK CONSTRAINT [FK_EMPLOYEES_EMPLOYEES] GO ALTER TABLE [BOSTON_USERS].[EMPLOYEES] WITH NOCHECK ADD CONSTRAINT [CK_BIRTHDATE] CHECK (([BIRTHDATE] The above batch will create a new database named Boston and then switch the database context from master to this new database. Within the Boston database, we create the schema Boston_Users and then copy the structure of the Northwind.dbo.Employees table to the new Boston_Users.Employees table. We also modify the Northwind table a bit by appending a "_z" to the column names. Now, we have two tables with identical table names and partially different column names. We now switch to ApexSQL Diff and create a new data comparison project. As source for the comparison, we choose the Northwind database. For the destination database, we use the Boston database. In the Data Comparison Wizard, we go to the Mapping Columns page where we can select the columns to be matched. The screen will look like the one below:  Let's focus on "Columns" of the above grid:  Opening the list displays the following screen:  The list is divided into two parts. The upper part displays the mapped column pairs. The lower part displays the unmapped column pairs. By default, ApexSQL Diff automatically has mapped the columns with the same name. These pairs are shown in the upper part of the list. The lower part contains the columns that were modified earlier:  As with every Source/Destination visual control element in ApexSQL Diff, on the left side you can see the information pertaining to the Source side of the comparison. The right side shows the information pertaining to the Destination side of the comparison. Unmapped columns will be ignored by ApexSQL Diff during a Data Comparison Project. Thus, they will not be synchronized. In order to include these column in the comparison and sychronization, map the columns as you would map tables. Select the corresponding "Destination Name" from the dropdown box of that field:  In the above example, "EmployeeID" is mapped to ":EmployeeID_z". It can now be found in the upper part where all other mapped items already are:  Once all the unmapped columns are mapped, the result is as below:  The lower part is empty as all previously unmapped columns are now mapped. All columns in both tables will now be included in the comparison and synchronization process. SEE ALSO Mapping in ApexSQL Diff, Part 1: Schemas Mapping in ApexSQL Diff, Part 2: Tables AUTHOR Frank Kirkland LAST REVIEW DATE 30 August 2007 Labels: Apex SQL Diff ...Mapping in ApexSQL Diff, Part 2: Tables DESCRIPTION This is the second installment in the three-article KB series discussing ApexSQL Diff's mapping ability. With ApexSQL Diff, you can map users/schemas, tables, and columns. Here, we discuss how to map tables. What does "mapping tables" mean? As mentioned in Mapping Schemas, ApexSQL Diff runs in two different modes: Structure mode compares and syncs database structures and Data mode compares and syncs data. Mapping tables applies only to Data mode. By default, ApexSQL Diff automatically maps objects of the same object type and object name and have the same schema. That is, when you have a schema "DBO" in both the source and destination of your project, and both own the tables named "MyTable", these tables will automatically be mapped by ApexSQL Diff. However, when the schemas in both source and destination differ in their names, mapping is not automatic. This is the case even when the object names in the schemas are all equal; the tables will still be unmapped. To address this, ApexSQL Diff allows mapping tables manually. Mapping tables To reproduce the situation, let's issue the following batch: USE MASTER CREATE DATABASE BOSTON GO USE BOSTON GO CREATE SCHEMA BOSTON_USERS AUTHORIZATION DBO GO SELECT * INTO BOSTON_USERS.EMPLOYEES FROM NORTHWIND.DBO.EMPLOYEES The above batch will create a new database named Boston and then switch the database context from master to this new database. Within the Boston database, we create the schema Boston_Users and then copy the structure of the Northwind.dbo.Employees table to the new Boston_Users.Employees table. We now have two tables with identical names and identical data. The important difference is, they are contained in different schemas. We now switch to ApexSQL Diff and create a new data comparison project. As source for the comparison, we choose the Northwind database. For the destination database, we use the Boston database. In the Data Comparison Wizard, we go to the Mapping Tables page where we can select the tables to be matched. The screen will look like the one below:  The grid above the red rectangle is empty because ApexSQL Diff cannot automatically map the Employees table. Although the object types and names are identical, their containing schemas differ. The table pair (dbo.Employees/Boston_Users.Employees) is yet unmapped, and therefore is found in the "Unmapped objects" grid:  Below, the two Employees tables are presented on two different rows:  To map the two Employees tables, place the cursor in the Name column on either row where the Employees table is displayed:  Expand the dropdown list:  Notice the red arrow above. This simply shows that the Unmapped Objects grid is a two-way grid. Meaning, you can achieve the same result when you click either on the dropdown box in Name column in the "Destination half" or the Name column of the "Source half" of the Unmapped Objects grid.  To map two tables permanently in this project, click the "Map" button:  Alternatively you can use the "Map" command from the context menu of the Unmapped Objects grid:  The table pair is immediately moved from the Unmapped Objects grid to the Mapped Objects grid.  You have successfully established a "permanent link" between two tables residing in different schemas. The table dbo.Employees and the table Boston_Users have the same set of columns. What if they were different? This is what we will discuss in the third and last installment. SEE ALSO Mapping in ApexSQL Diff, Part 1: Schemas Mapping in ApexSQL Diff, Part 3: Columns AUTHOR Frank Kirkland LAST REVIEW DATE 31 August 2007 Labels: Apex SQL Diff ...Mapping in ApexSQL Diff, Part 1: Schemas DESCRIPTION This three-article KB series discusses ApexSQL Diff's mapping ability. With ApexSQL Diff, you can map users/schemas, tables, and columns. This first installment discusses mapping schemas. The Testing Environment For this KB series, we will be using the Northwind database on a SQL Server 2005 Developer edition. The Northwind database is a good sample database because-- (1) It is shipped with SQL Server 2000 and so is readily available to a broad audience. The instnwnd.sql script which creates it is available on the Install folder of SQL Server 2000. It is also available for download here. (2) It works with all SQL Server versions supported by the ApexSQL tools (version 7.0, 2000, and 2005). Though SQL Server 2005 ships with a whole new sample database called AdventureWorks, the Northwind database continues to be popular among the SQL Server community and hence, we use it here. What does "mapping schemas" mean? ApexSQL Diff runs in two different modes: Structure mode compares and syncs database structures and Data mode compares and syncs data. Mapping schemas applies only to Structure mode. SQL Server databases consist of system and user-defined objects of different object types. These objects can be stored procedures, views, tables, etc. Common to all objects is that they are owned by an owner. These owners are called user in SQL Server 2000 and older. They're called schema in SQL Server 2005. Throughout this article, we define users and schemas basically as containers for objects and, for simplicity's sake, we will use the term "schema" to refer to both. (For a more detailed discussion of the similarities and differences of user and schema, refer to the User-Schema Separation section of SQL Server Books Online. We can map user to user, user to schema, or schema to schema. With the exception of features exclusive to SQL Server 2005, you may compare and synchronize SQL Server 2000 and SQL Server 2005 databases in one single project. Mapping schemas enables you to compare objects that belong to the same or different schemas. By default, Apex SQL Diff automatically maps schemas of the same name. That is, suppose you have a "dbo" schema in both the source and destination of your project, they will automatically be mapped by ApexSQL Diff. This is not the case when the schema of the objects for comparison are different. Mapping would then have to be done manually. Mapping Schemas manually Typically, schemas in the databases being compared are the same. In such cases, no schema mapping is required and all necessary comparison steps are carried out by ApexSQL Diff automatically. It is not uncommon however to compare databases with objects that have different schemas. To illustrate, suppose there exists a database which stores data for different clients. The database may be designed such that each client represents one schema. Suppose every client has a corresponding Employee table which has a pretty similar structure to the Employee tables of the other clients (do ignore the questionable design--this is just for illustration purposes albeit I am sure such design exists somewhere). In this case--manual mapping is necessary. The Example To reproduce the example, let's issue the following batch: USE MASTER CREATE DATABASE BOSTON GO USE BOSTON GO CREATE SCHEMA BOSTON_USERS AUTHORIZATION DBO GO SELECT * INTO BOSTON_USERS.EMPLOYEES FROM NORTHWIND.DBO.EMPLOYEES WHERE 1=0 The above batch will create a new database named Boston and then switch the database context from master to this new database. Within the Boston database, we create the schema Boston_Users and then copy the structure of the Northwind.dbo.Employees table to the new Boston_Users.Employees table. As we are not interested in data differences between the two tables, we have added the WHERE clause 1=0 which always evaluates to FALSE and therefore just executes the underlying CREATE TABLE process to create the table Boston_Users.Employees. This does not copy over any of the data. We now have two tables with identical names, identical data (zero), but different schemas. Using ApexSQL Diff We now switch to ApexSQL Diff and create a new structure comparison project. As source for the comparison we choose the Northwind database. For the destination database, we use the Boston database. In the Structure Comparison Wizard, we go to the Mapping Schemas page where we can select the schemas to be matched. The screen will look like the one below:  To establish the permanent linkage between these two schemas in this project, we click on the "Add" button,  : The schema pair is displayed in the grid below and visually represents above linkage:  We can simply repeat this process until we're finished. We can even map a schema (Source or Destination) more than once to another schema (Source or Destination). That's basically all we need to do. In summary, all we've done is tell ApexSQL Diff that during comparison, the database structures in the dbo source schema and the Boston_Users destination schema should be compared. Some helpful features There are several additional buttons in the Schema Mapping page of the Comparison Wizard and we discuss them briefly here. Delete The "Delete" button is the reverse of the mapping operation: it unmaps two schemas. To Delete a mapping, we put the cursor on the row that displays the schema pair we want to unmap and click the Delete button. Import and Export Suppose we have many SQL Server databases in our environment that we need to synchronize on a regular basis. Suppose further that these databases have very similar schemas. In this case, we can create a schema mapping that is applicable to the other databases and save it. We do this by clicking Export  after we have completed mapping our schemas: The "Export Owner Mapping" dialog appears as below:  We save  the Exported Owner Mappings File (which is in XML) to the desired location. The default filename is "Owner Mapping.axmp". To use this mapping file in a Structure Comparison project, we import it to the project by clicking the "Import" button,  : We open  an Owner Mappings File and this loads a previously saved mapping into the project. Conclusion This is how simple schema mapping is. In the next installment, we will discuss how to map tables. SEE ALSO Mapping in ApexSQL Diff, Part 2: Tables Mapping in ApexSQL Diff, Part 3: Columns AUTHOR Frank Kirkland LAST REVIEW DATE 27 August 2007 Labels: Apex SQL Diff ...Tech Tip: Using Row Filter Feature in ApexSQL Diff (Data) DESCRIPTION This tip describes how to use the Row Filter Feature in ApexSQL Diff to limit the comparison to a specific subset of rows. SOLUTION Use the rows filter to limit the number of rows to be loaded at the same time if your goal is to only compare a subset of data. To do this, simply make use of the Filter column in the Object Filter > Data Tables grid.  For example, if we add this filtering to the Address table of the AdventureWorks database (and to the database it is being compared with), only rows with AddressID < 20 will be loaded. The filter column is especially helpful when the tables you are dealing with include an "updated date" column. This way, you can just load records for a specific date/time range (e.g. load only records updated within the last two days). The Row Filter dialog consists of two panes. On the left pane, you can enter a WHERE clause that will filter the data in the column of the Source object. You can use a different row filter condition on the Destination object. In cases, where you want to use the same condition on both tables/views, you can simply check the “Use the same filter condition for both objects” option. If this option is checked, you only need to type your condition once. ApexSQL Diff will automatically apply the filter on both objects during the comparison. Click on the OK button to save your row filter condition and close this dialog or click on the Cancel button to discard your settings. AUTHOR Janice Lee LAST REVIEW DATE 8 August 2007 Labels: Apex SQL Diff ...How to Sychronize a Database on a Schedule DESCRIPTION There are times when you want to run ApexSQL Diff operations on a schedule. For example, you may want to sychronize your testing and production databases every night (during downtime). This KB article describes how to schedule a database sychronization in ApexSQL Diff. (Note: You can use the same approach in, for example, ApexSQL Log if you want to read the transaction log on a desired frequency and schedule). SOLUTION To schedule database sychronization, use the free command line interface that comes with ApexSQL Diff (and all other ApexSQL Tools) together with Windows'/SQL Server's scheduler. To illustrate, let's use 2 databases: TestDB (testing database) & ProdDB (production database): UID/PWD for TestDB: TestDBsa/password1 UID/PWD for ProdDB: ProdDBsa/password2 To sychronize TestDB with the ProdDB, the following command needs to be executed: apexsqldiff.com /s1:server_name /d1:ProdDb /u1:ProdDBsa /p1:password2 /s2:server_name /d2:TestDB /u2:TestDBsa /p2:password1 /sync To run this command every Sunday, 10 pm, schedule it using SQL Server or Windows' scheduler. To schedule using SQL Server: 1. Open SQL Server and create a new job:  2. To run the job every Sunday, 10PM, create a new sched as shown below:  To do this using Windows' Scheduler: 1. Open Scheduled Tasks and double-click Add Scheduled Task.  2. In the Scheduled Task Wizard, click Browse and go to ApexSQL Diff's application folder and select apexsqldiff.com  3. Assign a name for the synchronization job and specify frequency.  4. Select the time and day you want the task to start.  5. Specify login credentials as necessary.  6. Check Open Advanced Properties before clicking Finish.  7. In the Run textbox of Advanced Properties, type in the following and click OK. "C:\Program Files\ApexSQL\ApexSQLDiff\ApexSQLDiff.com" /s1:server_name /d1:ProdDb /u1:ProdDBsa /p1:password2 /s2:server_name /d2:TestDB /u2:TestDBsa /p2:password1 /sync  You may use any of the above approaches to schedule your database synchronization. AUTHOR Janice Lee LAST REVIEW DATE 21 August 2007 Labels: Apex SQL Diff ... |
© 2007 Apex SQL Tools All Rights Reserved | 1.919.968.8444 | Contact Us | Terms of Use