Sybase

Both DB-lib and CT-lib are libraries that implement the TDS protocol from the client side.

DB-lib

DB-lib was Sybase's first version. It was a good first attempt, but has/had a number of inconsistencies. There are, or possibly were, a lot of applications written using DB-lib. If you are about to start a new Open Client development, consider using CT-lib, it is the preferred choice. (What version of TDS does DB-lib, is it only 4.2?)

Having said that you should use CT-lib for new developments, there is one case that this may not be true for and that is 2 phase commit. 2 phase commit is supported directly by DB-lib but is not supported directly by CT-lib.

CT-lib

CT-lib is a completely re-written version of Open Client that was released in the early '90s. The API is totally different from DB-lib, and is much more consistent. Applications written using DB-lib cannot simply be compiled using CT-lib, they need a significant amount of porting effort. CT-lib is newer, more consistent and, in several people's opinions, including mine, slightly longer winded. Having said that, the future of DB-lib is uncertain and is certainly not being developed any more, as a result all new apps should be written using CT-lib.

There are pros and cons to both, however, I think that it should be stated up front that RepAgents are the latest offering and I believe that Sybase would expect you you to use that. Certainly the documentation for LTMs is a little buried implying that they do not consider it to be as current as LTMs.

LTM Cons:

* Older technology. Not sure if it is being actively supported.

* Not integrated within ASE, so there is a (small) performance penalty.

* Separate processes, so need additional monitoring in production environments.

LTM Pros:

* Possible to restart LTM without having to restart ASE.

RepAgent Cons

* If it crashes it is possible that you will have to restart ASE in order to restart RepAgent.

RepAgent Pros

* Latest, and presumably greatest, offering.

* Tightly integrated with ASE so good performance.

* Less to manage, no extra entries in the interfaces file.

Check the Obvious

First, ensure that you are only replicating those parts of the system that need to be replicated. Some of this is obvious. Don't replicate any table that does not need to be replicated. Check that you are only replicating the columns you need. Replication is very sophisticated and will allow you to replicate both a subset of the columns as well as a subset of the rows.

Replicate Minimum Columns

Once the replication is set up and synchronised, it is only necessary to replicate those parts of the primary system that actually change. You are only replicating those rows and columns that need to be replicated, but you only need to replicate the actual changes. Check that each replication definition is defined using the clause:

create replication definition rep_def_name

with primary