Skip to Content
avatar image
Former Member

Is there a Don'tPassthrough in SQL Remote?


I've found a couple of records in the consolidated that are out of step with the remote. However the remote has the correct data. Is there a way I can execute some updates on the consolidated database and not have them replicated by SQL Remote? The Passthrough documentation implies that the update could be run on the Remote (which is a couple of thousand miles away) but then how do I prevent the remote database being updated?

Thanks for any ideas,


Please don't say 'mess with log offsets'  <<shudder>> 😊

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Best Answer
    Jul 14, 2014 at 12:37 PM

    Forgetting the features and rules of SQL Remote for the moment, what exactly do you want to happen? (from your databases' point of view).

    What exactly do you know about the current situation? (e.g., do you know what the affected rows contain in all the columns, or do you just know the primary keys, or something else?)

    Is the situation stable for the affected rows? Or are they being repeatedly updated and replicated?

    What version of SQL Anywhere are you running on the consolidated and remotes?

    (no, don't mess with offsets, that never works for mortals)

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member

      Hi Breck,

      I know everything about the two rows in question, except how they came to be out of sync (in 2008 it would seem). They won't be updated in the normal course of things for the time being, as they are effectively dormant.

      However, the problem is that the value of one column in each of the rows causes them to be included in some "medical tests" from which the people they relate to should be excluded. This happens at the consolidated where the value is incorrect. At the remote that value in the column is correct and the rows are excluded. The table in question records the person's status over time and for audit and legal purposes must accurately reflect the historical changes.

      The goal is to update the the offending column in each of the two rows at the consolidated and not have any replication take place. It did occur to me that I might take the table out of the subscription, update and put it back but that would be tough to manage as we run 24x7.

      We are running SQL Anywhere

      Thanks, Paul