on 2010 Jan 27 6:35 PM
I have some table :
create table people
(
id bigint not null default autoincrement,
first_name varchar(50) not null,
last_name varchar(50) not null,
gender char(1) not null default 'M',
last_update timestamp not null default timestamp
);
What happens in a replicating environment if remote user 1 updates a row, and then replicates the change to the main site? Does the last_update get updated AGAIN at the main site when the change arrives and is processed?
Please tell me it doesn't.
Request clarification before answering.
Calvin,
it doesn't.
When you look at the SQL statements that are sent to the other side (by running DBREMOTE -v -o C:\\´MyLog.txt) you will notice that the receiving database gets a complete statement with the *last_update* column set. And the particular DEFAULT TIMESTAMP default will only be applied when the column's value is not set explicetely. So no need to worry, we have used this DEFAULT in a SQL Remote setup for years.
As to your new example: If the remote exeucutes the following SQL statement (say, in a client app):
UPDATE people SET last_name = 'Smith' WHERE id = 123450000
then last_update will be set automatically to current timestamp (say, to '2010-01-28 11:24:23.123456'). The transaction log will then contain something like (you could check by using DBTRAN):
UPDATE people SET last_name = 'Smith', last_update = '2010-01-28 11:24:23.123456' WHERE id = 123450000
And it's that statement that is sent to the consolidated. Obviously, the statement contains a value for the DEFAULT TIMESTAMP column, so it doesn't update *last_update* again.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
52 | |
10 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.