forums › forums › SQLyog › Using SQLyog › Protecting A Single Cell Of Data
- This topic is empty.
-
AuthorPosts
-
-
June 16, 2007 at 7:04 am #24296
peterlaursen
ParticipantIf I understand you correctly, you can do this:
create a batch file that exectues
– a SJA sync job
– a SJA notifications job that does the UPDATE
and you can execute and/or schedule the .bat file
refer to: http://webyog.com/faq/27_35_en.html
-
June 16, 2007 at 2:24 pm #24297
Mike Penta
Memberpeterlaursen wrote on Jun 16 2007, 03:04 AM:create a batch file that exectues– a SJA sync job
– a SJA notifications job that does the UPDATE
and you can execute and/or schedule the .bat file
Perfect – I knew the program could do this, I just didn't know where to look. It works just as I need it to, thank you.
I wasn't certain if your answer was also an answer to my 'can you filter out certain columns from the updating process,' so let me describe what I meant with a little more clarity. It would be a great feature if it wasn't one.
Lets say I have a table with 3 columns: A – B – C. They each have several rows of data. And lets say the data in column B I want to be left unchanged.
Currently – If I have the sync look at column A and C, and it finds a checksum difference – It replaces the whole ROW. This means the data in column B is overwriten.
What I would like to have happen – Have the sync look at column A and C in each row, and if it finds a checksum difference, it only replaces the data in Column A and C, and not changing the data in column B.
-
June 16, 2007 at 2:31 pm #24298
peterlaursen
ParticipantNo .. you cannot 'filter out' columns. SQLyog/SJA data sync will always sync complete rows.
The
specification is used to select only specific columns for calculation of checksums and not sync. If for instance you have a unique column (more than the PK) you can speed up things by onlyusing this one for checksums.
Please refer to the article (that still is almost correct):
-
June 16, 2007 at 2:35 pm #24299
peterlaursen
Participantand btw: I think your request is extremely dangerous (though of course there will always be situations (users + data) where everything may make sence). That would very easily become a 'out-of-sync tool' that way!
The only solution I can propose right now is to 'split' the table into two or more tables – one with data that shall sync, another with data that shall not.
-
-
AuthorPosts
- You must be logged in to reply to this topic.