[peterlaursen]

Quote:

Is this planned?

Let us say it is being considered!

We need to implement two more features with the option to do this.

1) the delete-trigger type should remove 'orphaned' rows in the ODBC-source

2) the update-trigger type should query MySQL and the fetch the values to update with.

Agree it would be nice! And I think it could be done with most ODBC-drivers. Not the ODBC-text-driver and I believe dBase and similar 'early' ODBC implementations would have problems too.

[peterlaursen]

to be specific:

If 'lower_case_table_names' is '1' or '2' on both servers sync should be case insensitive

If 'lower_case_table_names' is '0' on both servers sync should be case sensitive

If 'lower_case_table_names' is '0' on one server and '1' or '2' on the other sync should be case sensitive as default. However if there is no conflict a popup could display offering to do the sync anyway. And to avoid server errors the name-CASE of the table on the server where it is case sensitive should be use.

This applies to STRUCTURE SYNC and DATA SYNC as well.

Did I get it all? 😮

[peterlaursen]

and FAQ write-up accordingly:

http://webyog.com/faq/index.php?action=art…ase%20sensitive

[peterlaursen]

we are a lot of 'former's 🙂

But you are missing an important point:

Case sensivity with *NIX and Non-case sensivity with Windows (and sometimes MAC, depending on the filesystem on which it is installed) are only DEFAULTs for the systems. The behaviour can be changed with the 'lower_case_table_names' system variable on all platforms.

So where appropriate SQLyog should query this system variable and adjust its CASE SENSIVITY accordingly!

[peterlaursen]

@ritesh:

When is monday?

Monday February 19th 2007 ? 😛

I checked SQLyog 5.1 beta1. Seems to work fine now. No table is created and then dropped. However a small cosmetics:

The

Code:

drop view if exists …

is repeated twice for each view.

[peterlaursen]

One more question:

Do you generate BULK INSERT statements?

If so the BULK SIZE will be as big as the max_allowed_packet setting of the MySQL server. That might be too much for PHP with the current cofiguration!

Ritesh has promised me that BULK size wll be made user configurable in near future (no later than SQLyog 5.2).

[peterlaursen]

Also ..

do you use the 'ordinary' export option or the 'powertool' backup option of SQLyog Enterprise?

If 1st is the case, you my try the latter (demo available if you don't have Enterprise)

EDIT: Of course you have Enterprise since you are able to tunnel!. Silly remark from me! 😎

[peterlaursen]

This

Quote:

MySQL client run out of memory

now .. in this case is the MySQL client the SQLyog program or the PHP binary? I am not sure!

Do you have access to php configuration?

[peterlaursen]

Correction:

it should write simply

Code:

insert into `testtable` (`mytext`) values ('d')

I don't believe you will ever make this work unless you understand that COLUMN DEFAULTS should handled by the server and not the client. Simply skip empty cells when generating an INSERT or UPDATE statement as you allready do with TIMESTAMPs defined as 'on update CURRENT_TIMESTAMP' when there are data in them.

In NON-STRICT mode as used by SQLyog connections this will never generate an error.

[peterlaursen]

Quote:

as soon as an alpha release of 5.1.8 is released

MySQL 5.1.7 will be released as BETA as I understand, so 5.1.8 probably too 😀

Actually 5.1 is comming fast – much faster than 5.0. I think it is final before the end of the year!

[peterlaursen]

I can insert Danish characters into a BLOB column using HTTP with no problem.

But not into a TEXT or VARCHAR. This is true for PHP 4.4.2 and 5.1.2 on my locals and for 4.4.2 on my own webhost.

But on a server running PHP 4.3.2 (you know which one!) I can HTTP-write æøåÆØÅäöüëéñ etc in BLOB, TEXT and VARCHAR columns as well.

@ritesh

doesn't that (that BLOB write and TEXT and VARCHARS don't) more or less prove that it is not an issue with SQLyog?

I really start to suspect that the latest PHP builds are buggy – or the connectors distributed by MySQL!

[peterlaursen]

Now this is very very interesting:

http://bugs.mysql.com/bug.php?id=17458

However my HTTP-write problem occurs also with MySQL 4.0 and tested same with php 442 and 512.

But no matter what this thread is worth bookmarking!

[peterlaursen]

Quote:

If sync'ing a LINUX server with a Windows server (with their default settings)? …  But the SJA SCHEMA can't handle this as of now. Right?

Wrong actually I believe after thinking a little! If the jobfile uses the table-names of the Unix-machine, it should work!

[peterlaursen]

also:

it should not be either case-sensitive or case-insentensive – it should be both! And adjust according to the 'lower_case_table_names' settings of the server(s).

Now (an these questions apply to STRUCT SYNC and DATA SYNC as well):

If two servers have different settings – what then?

If sync'ing a LINUX server with a Windows server (with their default settings)?

I see no other option than an additional popup to ask user what to do if things are ambigious. But the SJA SCHEMA can't handle this as of now. Right? How to data sync TABLE on Windows with table on Unix?

[peterlaursen]

@ritesh

DATA SYNC also has problems. With my example it should not even attempt to sync! Tables are different. There are no tables to sync. But it sees them as identical. However the the server does not agree (!) and thus the error.

This is an error in SQLyog.exe. That does not exclude errors in sja.exe!

Also – if you run a MIGRATION, BACKUP, or NOTIFY job and connect to a DB with a table and a TABLE – are you sure that it tries to read from/write to the right table? It should be checked! Though it could very well be that it affect only tools involving two MySQL datases with the task/job.

[Author]

Posts