[peterlaursen]

verified!

Thanks for your research!

[peterlaursen]

additional comment to image #2:

It is of course the settings in the SMALL dialogue box you should notice.

[peterlaursen]

It took 1-2 minutes for me with OpenOffice Calc 2.2.1. See attached 'cartoon'. But OK this is a very simple example that uses the OO default save settings only (and does not use decimal numbers). In this OOcalc version you define the data seperator and the enclose character for strings when saving by selecting 'edit filter settings' (translated from Danish). If you have decimal number using Continental European decimal notation, I noticed that OO convert them to strings in the CSV if you do not select another seperator character than ','.

There really are lots of different CSV format 'variations' that we need to support! It is CSV that is the problem, not SQLyog I believe. It would be nice if it was simpler, but there there would be situations that could not be handled correctly if we did not provide the options that we do.

We provided the 'Excel Friendly' option for ease of use, but I can tell that I opposed this internally because it DOES NOT WORK with Continental European decimal notation! That illustrates the conflict: making things easy introduces errors!

BTW: I also verified that it work the same with ANSI/UTF8/UTF16 encoded files

[peterlaursen]

please attach

* a small sample CSV file (a few rows, a few columns)

* a screenshot of how the same displays in OpenOffice Calc

[peterlaursen]

I think you are running Windows Vista?

there are Forums threads:

http://www.webyog.com/forums//index.php?showtopic=3366

http://www.webyog.com/forums//index.php?showtopic=3330

a reboot will normally solve the issue when it occurs.

We are trying very hard to solve this before releasing 6.06 FINAL.

[peterlaursen]

I will ask a test engineer to look into it.

But we will check against the 6.06 and 6.1 code tree primarily.

What is your windows version?

Did you try rebooting after gettings those errors?

[peterlaursen]

No direct idea, but could you possibly upgrade the server? Latest stable is 5.0.45 and 5.0.22 is pretty old and buggy. (I would say anyone using a version before 5.0.28a should upgrade immediately).

What is the EXACT statement causing this error. Does HISTORY tell?

Can you attach a sample .csv (please ZIP it) causing this error and a screenshot of your import settings?

[peterlaursen]

If the full name of Jay Shi is 'Jay Jianxin Shi' we have a match in our database. Original purchase 2005-08-12; version 5.19 would than be the latest free upgrade for this purchase.

We will need more info about the type of database and maybe also the structure and data! What we know now is only like 'I start my car, but the engine goes out immediately. But once it worked' . What kind of car, how is it fuelled etc …. ?

Please also explain what was the difference when it succeded and not. Only the amount of data? Can you repeat the success?

If do not believe in 'workarounds' for tis! If there was an issue with 5.19 and still is in 6.x we will of course fix it. But fix is possible only in future versions!

If you import more tables you can try one table per job to find the problematic one.

[peterlaursen]

Because it is a crap server, a crap connection or a crap program!

2-1 in favour of SQLyog! 😛

Jokes apart: please answer:

* Is it 100% consistently reproducable that sync always stops the very same place? it may then be a data specific error. But I have been using data sync with phpbb2 quite a lot about 1 year ago wihout problems. In the example you pasted 6 complete tables were sync'ed (actually they were all in sync!) – the error occured while sync'ing the 7th. Row counts were retrieved but not checksums it seems.

Now try only this table! Is the error consistenly reproducable with the `phpbb2_config` table?

* How do you connect? direct, SSH or HTTP tunnel? You never experience that you lose connection for instance when importing huge amounts of data? Running data sync over HTTP needs a reasonable stable HTTP connection!

[peterlaursen]

If you are a new user how could it happen that you are using an old version? We stopped distributing this version back in October 2006. I also find no reasonable match in our customer database with your details (name and email address). SQLyog Enterprise is NOT free software!

Basically if makes no idea to discuss any such issue with version 5.19 (we cannot fix issues in old versions – only in new versions!). Please test with latest version if problems persist. You can download a TRIAL from our download page if you are not able to download a registered version. The TRIAL is restricted to import max. 2 tables per job, but no other restrictiin for the month it will run.

If they do we need (for a start) more information about

*what kind of database it is (including version). 'network database' does not tell much!

*information about the odbc driver

(we will probably need more specific info after that, but what we need depends on the answer to those questions)-

But first of all try 6.05 or 6.06!

[peterlaursen]

OK .. one more issue with scroll.

We know we have such issues. We plan to fix each and everyone in 6.2. The reason for this 'delay' is that we plan to introduce FORMs here – and that will make use of a 'flipped' GRID. So FORMs and the scroll issues will most efficiently be done together.

However let us se tomorrow if this particular issue is an easy fix. Then it will of course be done in 6.06 or 6.1.

[peterlaursen]

Code:

Do I need the enterprise version to be able to use job agent?

SJA or Windows comes with SQLyog ENTERPRISE only. SJA for Linux is free.

[peterlaursen]

I think a 'sproc' is a Stored Procedure?

SJA consist of 4 'modules':

*Data sync

*Migration (ODBC)

*Scheduled Backup

*Notifications Services

You can call a 'sproc' from Notifications Services, refer to:

http://webyog.com/faq/content/27/114/en/in…agent_-sja.html

http://webyog.com/faq/content/14/81/en/is-…s-service_.html

Peter Laursen

'wyfwad' (WebYog Forums WAtchDog) 😉

[peterlaursen]

In SQLyog right-click the table in the Object Browser .. change tabletype to .. InnoDB. Do this for every table that you wnat be 'parent' og 'child' table in a Foreing Key ('relationsship)

[peterlaursen]

nevertheless ..

after the discussion that has taken place in the bug report I posted to bugs.mysql.com we reached the conclusion that

we should not do this

/*!50003 DROP TRIGGER /*!50114 IF EXISTS */ `trigtest`.`tr1` */ ;

but instead

/*!50003 DROP TRIGGER */ /*!50032 IF EXISTS */ /*!50003 `trigtest`.`tr1` */ ;

That is two changes actually:

1) check for version >= 5.0.32 and not 5.1.14;

2) avoid 'nested comments';

You should notice that that will result in Syntax Error 1064 on MySQL versions 5.1.1 – 5.1.13. But better support stable version (5.0.32++) and recent betas (5.1.14++) than old betas!

We plan this change for version 6.06 FINAL.

[Author]

Posts