All of these databases have to set to accept UTF-8 compliant character sets to prevent corruption of non-ASCII characters.

Known Limitations:

  • Actian Vectorwise
    • Loaded via the bulk loader.
  • Azure
  • DashDB
  • DB2 has two severe limitations:
    • Tables may contain only 500 columns
    • The potential  width of all data must not exceed the database block size, which can be no greater than 32k, whether or not even the potential block size can be exceeded. Other DBMS platforms can create tables with the potential to create very verbose data but will fail at record insertion time only if the actual data exceeds the block size. DB2 won’t even let you create the columns that would allow you do to this. Since Salesforce objects typically have so many large text fields, nearly all text fields have to be defined as CLOB data types instead of VARCHAR, which means the record is physically stored in many separate database blocks, increasing the I/O and decreasing performance.
  • Greenplum
    • Loaded by the bulk loader.
  • MySQL has two limitations that can usually be dealt with:
    • A single row cannot contain more data than the block size, but you make CLOBs out of the large VARCHAR fields using the .
    • You’ll have to adjust /etc/my.cnf parameters as follows to accommodate your particular needs, using your best judgment as to what the exact values should be:
[mysqld]
default-storage-engine=INNODB
max_allowed_packet=32000000
innodb_buffer_pool_size=134217728
open_files_limit=10000
max_connections=500
  • Oracle
    • Excellent DBMS for flexibility. Spans database block size if data exceeds the width of the block. Requires a high level of skill to administer.
  • PostgreSQL
  • SQL Server
    • Excellent DBMS for flexibility. Spans database block size if data exceeds the width of the block. Very easy to administer.
  • Sybase
    • A single row cannot contain more data than the block size, unless you make CLOBs out of the large VARCHAR fields.
    • 16k limit on long text fields, which is a challenge because Salesforce allows 32k fields

Relational Junction for Salesforce will mirror your Salesforce data to Microsoft SQL Server, Oracle, MySQL, PostGreSQL, DB2, Sybase. It doesn't make any difference where the actual database is housed, but the Relational Junction server must be in the same Local Area Network to get reasonable performance. Sending data over the internet one record at a time doesn't scale very well. If you are going to use a collocated service, ensure that the database and the Relational Junction server are not in different data centers. Some of the services do not guarantee this.

Nearly all of our customers using on-premise deployment request and are provided a 2-week trial in which to kick the tires. The product is installed on a webinar with our support staff assisting, and you will get relevant training on the spot.

There is no trial for the Cloud deployment. However, we do provide a webinar demo showing how it works.

You can be up and running within 30 minutes. For the on-premise deployment, you’ll need

  • a computer with 16GB RAM and a 4-core processor,
  • either Windows or UNIX,
  • a UTF-8 character set database

The cloud deployment option is set up within hours of signing a contract.

The product will send you a daily log showing the records copied per object and whether added, updated, and deleted. There are also reject logs if record-level errors happen. You have access to these logs in the on-premise deployment option.

Yes, both cloud and/or on-premise backup storage options are offered. We have the ONLY product that offers both on-premise and Cloud deployment for backup and recovery. There is no surcharge for Cloud storage.

For the transport of data between SFDC and storage location, the Salesforce Partner API uses SSL and is approved by Salesforce.com. We are a certified product, and have been since 2005. There are many DBMS’s that offer SSL SQL connections.

For data at rest, if you chose the on-premise deployment, the database security is up to you. In our Cloud offering, the back end database is the encrypted Enterprise version of SQL Server on a server with no public access in an IBM data center. You do not have any access to even your own data in our Cloud offering.

As far as the auditability of security, if you use the on-premise deployment, you own the security. You can lock down your server so you have to log in to the server to access even the web user interface. If you use our Cloud deployment option, you have no access to anything. Recovery is done via a webinar in consultative mode where our professional services team does the actual recovery.

Yes. The only thing you’ll have to do is provide the URL of the Sandbox instance in the configuration. Product pricing is based on Production Salesforce orgs, so this is not even a factor.

Relational Junction for Salesforce backs up and will restore typically any Salesforce object that is allowed by the Salesforce API and security rules. You cannot create certain objects in Salesforce, such as AccountHistory, because it’s just not allowed by the Salesforce application. There are no issues with handling binary data, such as Attachments an Documents and ContentVersion.

It would be easier to tell you what Relational Junction for Salesforce doesn’t copy. This is a list of current objects that cannot be backed up because they are not “real” objects or have specific technical limitations of the API in copying records without some sort of specific qualifier.

ActivityHistory
AggregateResult
AssetTokenEvent
AttachedContentDocument
CollaborationGroupRecord
CombinedAttachment
ContentDocumentLink
ContentFolderItem
ContentFolderMember
DashBoardComponent
DataStatistics
DatacloudAddress
DatacloudCompany
DatacloudContact
DatacloudDandBCompany
EmailStatus
EntityParticle
FeedLike
FeedTrackedChange
FieldDefinition
FlexQueueItem
FolderedContentDocument
IdeaComment
ListViewChartInstance
LookedUpFromActivity
Name
NoteAndAttachment
OpenActivity
OwnedContentDocument
OwnerChangeOptionInfo
PicklistValueInfo
PlatformAction
ProcessInstanceHistory
RelationshipDomain
RelationshipInfo
SearchLayout
UserEntityAccess
UserFieldAccess
UserProfileFeed
UserRecordAccess
Vote

The Cloud deployment option — where Sesame manages the service in our Cloud — offers no data access to you for reporting. This would be a security concern, as well as causing performance degradation in our multi-tenant environments.

The on-premise deployment option gives you a relational database with indexed relationship fields for all table joins. You can use any Business Intelligence or reporting product. You can run this on your on-premise servers, Amazon AWS, or anywhere.