[peterlaursen]

did you check the 4.07 beta/RC-version ? It now displays the beginning of the string/data (using the defined character set for TEXT and the default character-set for non-TEXT, I believe)

A binary/hex view of data with the BLOB-viewer I know is on the TODO-list (and can't be far away).

Making the BLOB-viewer resizable is too.

This I don't understand:

Quote:

When I am trying to modify table data, I constantly have to swith between the Table Data & Result tab to determine which row to edit

You can edit from the RESULT-tab – you just will have to select the table to edit from the drop-down-box showing “Read Only” (this is security feature and very useful with multitable queries/JOINs)

[peterlaursen]

First report on new BLOB-viewer:

ICO not supported

Animated GIF's not supported (would be nice if 1st frame was displayed)

both 48/24 bit TIFF's supported (both uncompressed and .lzh-compressed – other (more recent) compression algorithms not tested)

both 48/24 bits PNG supported. Only interlaced format-version tested.

24 bit PSD supported / 48 bit PSD not supported (browser tries to display but can't) (PSD is the native Abobe Photoshop format. Although proprietary use of it is widespread).

Native paint Shop Pro image format not supported (browser tries to display but can't).

With formats supporting layers only image-files with one layer only is tested.

All test done with LONGBLOB field definition (a 48 bith uncompressed TIFF is about 35 MB with my camera resolution!). The memory handling of SQLyog is not optimal for such big binary DATA. Program soon get's very slow. And fails to display graphics after a while. After closing and restarting SQLyog it again works for a while … I don't want to hear that that is “as expected” – other programs handle it smoothly!

But after all that's a start!

[peterlaursen]

I don't know if this bug

http://www.webyog.com/forums/index.php?act…t=ST&f=6&t=1504

could have influenced ..

(it might have been in existence with SQLyog for a very long while)

and with 4.07 RC1 there's another bug

http://www.webyog.com/forums/index.php?act…�entry6208

I believe that 4.07 will be “solid as rock” when that last bug is fixed. It probably will be tomorrow.

[peterlaursen]

Other examples that fail

/*Data for the table `tablename1` */

insert into `tablename1` values (NULL,abcd);

insert into `tablename1` values (NULL,efgh);

insert into `tablename1` values (NULL,ijkl);

insert into `tablename1` values (NULL,mnop);

/*Data for the table `tablename1` */

insert into `tablename1` values (NULL,abcd);

insert into `tablename1` values (NULL,efgh);

insert into `tablename1` values (NULL,ijkl);

insert into `tablename1` values (NULL,mnop);

/*Data for the table `tablename1` */

insert into `tablename1` values (NULL,abcd);

insert into `tablename1` values (NULL,efgh);

insert into `tablename1` values (NULL,ijkl);

insert into `tablename1` values (NULL,mnop);

The following examples show that it is related to “NULL-fix”

With these examples numerical field is auto-increment (and thus not NULL)

and insert-stmts are correct

/*Data for the table `tablename1` */

insert into `tablename1` values (1,'abcd');

insert into `tablename1` values (2,'efgh');

insert into `tablename1` values (3,'ijkl');

insert into `tablename1` values (4,'mnop');

/*Data for the table `tablename1` */

insert into `tablename1` values (1,'a\b\c\d');

insert into `tablename1` values (2,'efgh');

insert into `tablename1` values (3,'i\j\k\l');

insert into `tablename1` values (4,'mnop');

[peterlaursen]

Quote:

This bug comes when you export resultset or table data?

Table! Right-clicking on table in object-browser.

The bug is new. Was not in 4.06 and 4.07 Beta1 (not sure about beta2). It is reproduced on MySQL 4.0.24 and 5.0.7

[peterlaursen]

well ..

we must start finding out whether it is export or import that fails!

I propose you do this:

Exporting with SQLyog you should try to uncheck the “Create Bulk Insert Statements” in the export dialogue.

Then SQLyog will only put one row of data in each stmnt – each on its own line in the .sql-file.

Then open file in an editor with line-numbers and check the number of insert statements and compare with count(*) on source server.

Actually unchecking the “Create Bulk Insert Statements” could prove to be a solution itself …

[peterlaursen]

Quote:

… discovered that record counts are different, as shown above

I can't explain this.

(BTW: where is above ?)

If could be a problem to copy the Forum php-code from one host to antother if MySQL and php versions are “too much different”, but it is not the reason why rows are missing with the data import. That could cause problems when running the BB-software …

[peterlaursen]

@ritesh

YEAH MAN …

simply exporting data (with 4.06 😛 ) replacing '.mp3' >> '.mp3' in a text-editor, importing to both host, then running these stmnts:

update mp3_filer set kunstner = 'abaki' where kunstner = 'abaji';

# (17 row(s) affected)

delete from mp3_filer where kunstner like '%duke%';

#(626 row(s) affected)

and then changing PK til “filnavn”

… sync returns:

Sync started at Thu Jun 30 20:13:48 2005

Table SrcRows TgtRows Inserted Updated Deleted

========================= ======= ======= ======== ======= =======

`mp3_filer` 38499 37873 626 17 0

Total time taken – 526 sec(s)

SO: issue confirmed fixed with +38.000 rows and PK containing -character

[peterlaursen]

thanks.

But I believe the issue I reported here at Jun 30 2005, 01:25 PM here is still open ?

[peterlaursen]

What about ICO and PSD ?

I intend to test with 48 bit formats later tonight (tif/png/psd) – also some BIG one's using MEDIUMBLOB's.

with the formats that support multilayered, transparent and animated data I shall try that too (to the extend that I have some relevant files… ).

[peterlaursen]

BTW:

With the final release you will provide doc's on which formats are supported ?!

[peterlaursen]

Quote:

I am eagerly waiting for the results.

I have posted in the thread.

[peterlaursen]

Doesn't work here! 😎

Did a fresh import to MySQL 4.0.24 (at localhost and webhost as well) of music data (you'll find a copy at my webhost )

executed these with the webhost (not your copy – mine only!):

update mp3_filer set kunstner = 'abaki' where kunstner = 'abaji';

# (17 row(s) affected)

delete from mp3_filer where kunstner like '%duke%';

# (626 row(s) affected)

Changed PK to “filename”

ran a sync with colums option: “filename” and “kunstner” and no SQL_WHERE.

result displayed:

Sync started at Thu Jun 30 16:32:21 2005

Table SrcRows TgtRows Inserted Updated Deleted

========================= ======= ======= ======== ======= =======

`mp3_filer` 38499 37873 0 0 17

Total time taken – 273 sec(s)

But I believe this display is wrong – it should be :

Sync started at Thu Jun 30 16:32:21 2005

Table SrcRows TgtRows Inserted Updated Deleted

========================= ======= ======= ======== ======= =======

`mp3_filer` 38499 37873 0 0 0

Total time taken – 273 sec(s)

(If I repeat exactly same job it keeps on displaying “17 deleted” and they can only be deleted once!)

However:

With your attached file I can see that filename is now exported as

'M:\Peters Musik\Abaji\Oriental Voyage\09 Kilmé.mp'

and not as

'M:\Peters Musik\Abaji\Oriental Voyage\09 Kilmé.mp3'

So I believe you “corrected” the defect with my data ?

So:

If you are perfectly sure that the failure to sync is because of the defect with my data, I believe it's not worth spending more time with it. But if you can propose a query or some other procedure to “repair” the defect “in batch mode”, I shal do that (something like changing to BINARY VARCHAR, remove the 0-character, and change back) !?

Changing PK to column “Guid” sync with columns_option = “Guid” and “kunstner” and no SQL_WHERE runs OK and even displays correctly

Sync started at Thu Jun 30 17:10:22 2005

Table SrcRows TgtRows Inserted Updated Deleted

========================= ======= ======= ======== ======= =======

`mp3_filer` 38499 37873 626 17 0

Total time taken – 569 sec(s)

BTW: I have one question here:

When using the “columns” -option will it then make any difference whether you specify the PK-column(s) or not ??

[peterlaursen]

Quote:

A BLOB datatype has a limit of 64K

Sorry – I missed that!

I shall do some more extensive test with various formats, fiesizes, and variations on BLOBs and TEXTs types (LONGBLOB/TEXT, MEDIUMBLOB/TEXT etc) tonight.

Right now I'm preparing a dataset for an extensive test with the -LIKE-PARSER case 🙄

[peterlaursen]

I tested with this reduced dataset and result of sync is OK

(I shall doto some tests with more extensive dataset tonight).

But this message is wrong:

Sync started at Thu Jun 30 15:22:24 2005

Table SrcRows TgtRows Inserted Updated Deleted

========================= ======= ======= ======== ======= =======

`testsync2` 17 14 17 0 14

Total time taken – 1 sec(s)

[Author]

Posts