[peterlaursen]

Isn't that almost the same thing that we do now?

http://webyog.com/faq/11_62_en.html

But I strongly recommend that if you use DATA SYNC without a PK that you understand how it works.

In this article

http://webyog.com/articles/Using_SQLyog_En…L_Databases.pdf

there is a paragrahp 'sync'ing without a Primary Key' at the end.

Quoting:

Quote:

Let us now describe more precisely how sync without a PK works:

1) First a number is retrieved by executing this SQL on the target with data being taken from the

source:

select count(*) from targetdb.table where col1=data, col2=data…..

If the count(*)-number is not zero in the target then the row exists in the target (as well as the

source). Then there is not anything more to do with that row (row exists in both source and

target) and the same operation is repeated for the next row of the source.

2) If the count(*)-number is zero then the row does not exist in target and a:

insert into targetdb.table values ( data1, data2,…. )

is generated and executed it in the target. This is the explanation that the two rows (that both

have been changed) are now considered to be two different rows. Actually there is no question

of UPDATE as it is not possible know which columns(s) to update. The select count(*)

statement only retruns a number (typically “0” or “1”). Or to put it another way: it returns

information of the existence of the data – not about the data itself! And querying detailed

information of each row of data is out of question for performance reason.

3) Finally SJA check for the need to perform DELETES: if the count(*) with data from the

target returns a non-zero number when executed on the target and a zero-number on the source

the row in target is deleted. Otherwise the process moves on to the next row.

Also note that the sync without a PK as it is described here is not able to distinguish between

situations where there is one row with a certain dataset and more identical rows with the same

dataset on the same server. More identical rows in source will result in sync to one row in target

only and one row in source identical to more identical rows in target will not trigger any action.

One row and more identical rows on the same host are simply considered identical situations.

[peterlaursen]

This is a DATA tab issue. From RESULT tab it is lightning fast. Also with tables having around 50 columns or more. So it is not the KEYWORDS check, but the responsivity of DATA tab as such that is the issue.

[peterlaursen]

Thx .. 🙂

yes that is the way it it …

[peterlaursen]

Here it takes around 1.5 seconds with that table,

that is still to much ….

That must be debugged where the time goes …

[peterlaursen]

@Ritesh

Well then

1) It will only reconnect when you execute query from the query window.

2) Use 'Table Data' tab to fill in dummy values …. SQLyog will try to reconnect from the GUI, two times and exit.

to me that sounds contradictory. 1) reconnect only from query window 2) will recomnnect from 'table data' GUI

What does the term 'query window' cover here then?

[peterlaursen]

“without migrating to a partitioned table, imports fine” and not to a partitioned …

It must then be an issue with MySQL itself. There is nothing here that SQLyog can 'influence' . All partions operations are performed on the server side alone.

I think you can import ito a non-partitioned table a create partions after import. Can you handle that yourself or need help?

I don't think MySQL will response positively to a bug.report from you using a third-party client. They will ask you to reproduce with command-line client! Better if we do then! After all we are 'MySQL Gold Certified Partners' . But we will need some debugging info to be able to.

Wait for Ritesh to comment on it … But probably we will need the table definition of the partitioned table and also some data to reproduce with.

“Is there a way to run this from the command line?” What ??

If you are talking about adding partitions after import you can use SQLyog/SJA 'Notifications Services' for that.

[peterlaursen]

” but how do I know if BETA or FINAL?”

program help .. about tells. But if you DL'ed from that link today it is the FINAL.

The problem is the connection to MySQL. And it is on 'localhost'.

hmmm … it can be hardware related (motherboard, harddisk) or software (protocol stack) related. It also can be an issue with MySQL 5.1 or SQLyog. Very hard to tell. Thinking ….

Running jobs like Migration, Sync etc will always demand a more stable connection that GUI operations do. Do you have a chance to test on another PC?

[peterlaursen]

No, it is not related to partitioning, I think. 'Sorting data into partitions' is done by the MySQL server itself. The SQL that SQLyog must generate is the same with and without partitions on the target.

“ERROR: 2006, MySQL server has gone away”

Are you using 5.12 FINAL and not a beta??

5.12 will reconnect if connection is lost. But of course there are limits to how unstable connection can be for it to work.

How do you connect to MySQL. Direct, HTTP, SSH ?

[peterlaursen]

I can figure out then that your head now smells like burned caramel ..

has it stopped smoking ? 😛

[peterlaursen]

I do not think that was the request:

He wrote:

“if we could also interface in our own applications with SQLyogs HTTP tunnel when SQLyog is open and running on the computer.”

I figured it as a 'powertool' opening a seperate window just like STRUCTURE SYNC does. Ideally the server side of the MySQL protocol should then be implemented here.

But both solutions are possible, I think

[peterlaursen]

you are right …

The progress bar can be confusing. It does not show any exact numbers. Just shows that it is running.

I have been thinking about this myself.

[peterlaursen]

@TomBez

you can 'work around' the issue by opening more program instances.

[peterlaursen]

Introducing the SCA = SQLyog Communication Agent 🙂

[peterlaursen]

This is very exiting, I think!

“if we could also interface in our own applications with SQLyogs HTTP tunnel when SQLyog is open and running on the computer.”

OK, SQLyog Enterprise must be installed and running, you say. Well, then it is no 'threat' and the 'secrets' remain inside SQLyog. What is needed is simply then a 'gate' in the program where external programs can 'throw' individual SQL-statements and have results returned. And that would then work with SSH, HTTP(s) and proxies as well.

To my best understanding implementation of that would only need the occupation of 1 or 2 ports for the communication and a very simple protocol. Maybe the existing HTTP-implementation can be used. And may even be possible to access it from a program running on another computer …

Wait for Ritesh to comment on that!

[peterlaursen]

done!

[Author]

Posts