---
title: Considerations for synchronizing from a database source
description: When synchronizing from a database to a directory or relational database management system (RDBMS) server, the following are recommended:
component: pingdirectory
version: 11.0
page_id: pingdirectory:pingdatasync_server_administration_guide:pd_sync_consids_sync_from_database_source
canonical_url: https://docs.pingidentity.com/pingdirectory/11.0/pingdatasync_server_administration_guide/pd_sync_consids_sync_from_database_source.html
revdate: September 13, 2023
section_ids:
  identify-database-entry-types: Identify Database Entry Types
  avoid-bidirectional-loopback: Avoid Bidirectional Loopback
---

# Considerations for synchronizing from a database source

When synchronizing from a database to a directory or relational database management system (RDBMS) server, the following are recommended:

## Identify Database Entry Types

Identify the database entry types that will be synchronized, and:

* Set the `database-entry-type` property on the Java database connectivity (JDBC) *(tooltip: \<div class="paragraph">
  \<p>A Java API that allows Java programs to interact with databases.\</p>
  \</div>)* Sync Source (this is required), and make sure the entry types are what the triggers are inserting into the change tracking mechanism.

* Create a Sync Class per entry type, and set different mappings and rules for each one.

For each Sync Class, do the following:

* Make sure the `include-filter` property is set to match the entry type.

* Create a specific attribute mapping *(tooltip: \<div class="paragraph">
  \<p>Matching corresponding attributes between an IdP and an SP to identify federated users or add supplemental user information.\</p>
  \</div>)* for every database column to be synchronized to an Lightweight Directory Access Protocol (LDAP) *(tooltip: \<div class="paragraph">
  \<p>An open, cross platform protocol used for interacting with directory services.\</p>
  \</div>)* attribute and set it on the Sync Class. If this is done, the script will not have to know about the schema on the directory side.

* Create a distinguished name (DN) *(tooltip: \<div class="paragraph">
  \<p>A name uniquely identifying an object within the hierarchy of a directory tree.\</p>
  \</div>)* map that recognizes the DNs generated by the script and maps them to the correct location at the destination.

* Remove the default value of "-all-" from the `auto-mapped-source-attribute` property on the Sync Class, and replace it with the value `objectClass`. The object class for the fetched source entry is determined by the scripted layer. Values from the database should not be automatically mapped to an attribute with the same name, except the `objectclass` attribute, which should map directly for CREATE operations. If this is not done, an error is generated.

* Change the destination-correlation-attributes property to contain the attributes that uniquely represent the database entries on the directory server destination.

## Avoid Bidirectional Loopback

Set the `ignore-changes-by-[user\|dn]` property on both Sync Sources when configuring for bidirectional synchronization, to make sure that changes are not looped back by PingDataSync.

See [Using the create-sync-pipe tool to configure synchronization](pd_sync_use_create_sync_pipe_tool.html) for details about creating the Sync Pipe.