[peterlaursen]

after saving from BLOB-viewer half of picture is missing.

[peterlaursen]

not quite yet ..

It does not hang and it does not crash anymore. But graphics still not always shown. Attached pic won't show in browser after it has been saved. It a simple jpg. Any filesize limit on what BLOB-viewer can handle.

Most important: I also experienced corruption of binary data when saving from BLOB-viewer. Actually I exprienced that more often than I experienced that saved data were OK

It's not safe!

[peterlaursen]

Quote:

Do you know when that version will be available?

Yesterday it was tomorrow (it is about 2 am here). So with some luck it will be as soon as the day after yesterday! 😀

Check the last post by Ritesh here:

http://www.webyog.com/forums/index.php?act…=6&t=1500&st=45

[peterlaursen]

some questions:

1) are there som “mods” with that forum. Some “mods” may alter the config tables of the DB. Other “mods” may alter the php-code. Porting a “modded” forum can be very complicated. Mods and data import have to be applied in the right order.

2) Did you copy your old php-code to new server (phpbb2-library) ?

3) MySQL and php-version on the servers ?

If SQLyog says that everything was imported it could be that not everything was exported ?

Data also may be there but not used by the code ?

Did you try the forum at http://www.phpbb.com/ ??

[peterlaursen]

Quote:

maybe I typed in an obscure pw

yes maybe … if you tried to use the name of your Windows' user account, then you can't connect! MySQL does not use the Windows' user management – it operates its own user accounts. That's a common misunderstanding with new MySQL users …

[peterlaursen]

maybe this is most illustrative:

/*this is correct */

/*************/

select 'backs\ash' like '%\\%'; /*returns 1*/

/* after stripped by LIKE-parser >> */

select 'backs\ash' like '%\%';

/* MySQL server pattern match actually check for >> */

select 'backsash' like '%%';

/*checks if -character is contained in literal string 'backsash' */

/* These are all wrong and return 0 */

/*****************************/

select 'backs\ash' like '%\%';

/* fails with LIKE-parser – like '%\%' becomes like '%%' after being stripped by parser

so with MySQL server pattern match it checks 'backsash' for match with “wildcard-meaning-% followed by literal-%” */

select 'backsash' like '%\\%';

/* fails with MySQL server pattern match – 'backsash' simply resolves to 'backsash' with MySQL server pattern match */

select 'backsash' like '%\%' ;

/* fails with both –

checks 'backsash' for match with “wildcard-meaning-% followed by literal-%” */

Goodnight from here – dream sweet 😆

[peterlaursen]

Finally I shall point out that this “” mismatch is not the reason for the failure of SJA to sync with “filename” as the PK. Simply because data on both hosts have this defect and thus the concat_ws() function will still return same result on both hosts. The failure of SJA is because of escaping style produced by SJA not taking WHERE .. LIKE filtering (“parsing”) into account.

Nevertheless I shall regret the confusion spread by me here and the time wasted … 🙁

[peterlaursen]

I tried to illustrate the principle of parsing of a query using WHERE .. LIKE

[peterlaursen]

Confirmed!

I did a fresh import.

created a small table with 1 row like

Code:

create table pl select url from track limit 1

Row url is the name of the one that I use to rename to filnavn/filename

Row is imported as BLOB, I convert to varchar(255)

Then export and open .sql-file in editor shows

/*

SQLyog Enterprise v4.07 BETA 2

Host – 5.0.7-beta-nt-max : Database – musik

*********************************************************************

Server version : 5.0.7-beta-nt-max

*/

create database if not exists `musik`;

USE `musik`;

/*Table structure for table `pl` */

drop table if exists `pl`;

CREATE TABLE `pl` (

`url` varchar(255) default NULL

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

/*Data for the table `pl` */

insert into `pl` values ('M:\Peters Musik\Duke Ellington\Jump for Joy\05 Jump for Joy.mp3');

If I don't convert to varchar but dump the BLOB result is the same.

Next tested with MySQl 4.0.24. Same result!

Next I tried to export form Access into MySQL (uses another (myODBC) ODBC-driver).

also produces insert into `pl` values ('M:\Peters Musik\Duke Ellington\Jump for Joy\05 Jump for Joy.mp3')

Tried with a few more columns and other colums imported as BLOB show same defect when data are automatically generated by player (read from mp3 file-tags for instance). Data imported as varchar never show this defect.

It must be a defect with data inherited from Access. And only data automatically generated by player (read from filesystem or file-tags for instance) show this defect – not when entered from keyboard into Access from Musicplayer GUI (“media library”).

So Sqlyog is not to blame. Musicplayer is.

Just One Correction: This column is not imported as PK. It might have been with some example posted. But in that case PK was created later.

[peterlaursen]

Quote:

SQL file for your table dump

which dump ?? Anyone special you looked at? From the server or one of the files that I attached ?

Quote:

you will see that there is an extra at the end of each primary key data

Yes – I noted myself in one of my postings that there was a mysterious “”

Quote:

Thus the WHERE clause fails.

Some of them. Others fail because of escaping style not taking WHERE .. LIKE filtering into account

Quote:

That is up to you to investigate

Any proposals for a methology ?

[peterlaursen]

I shall shut up until then!

I am fully confident that you will solve the problems

…………….. – with some help :wub:

[peterlaursen]

Quote:

so I have downloaded and with help from a SAMS book started to use MySql

Most books on MySQL are outdated. With the new installer for Windows and the “MySQL System Tray Monitor” installed with “MySQL Administrator” and preconfigured command line tool accessible directly from startmenu most of the “exercises” described in various books to get MySQL running are not necessary ….

What is your MySQL version? Did you get it from dev.mysql.com ? There are som obscure builds available on the internet 🙁

[peterlaursen]

My conclusion:

Parser is OK (you might even find it logical!), but error with data import (trailing “invisible” blanks)!

Since that is reproduced with 4.0.24 and 5.0.7 I really doubt that this is an issue with MySQL.

[peterlaursen]

I believe I can now understand, predict and verify the behaviour of all the example queries that I posted here.

Some examples are allready given.

here some of the most tricky ones:

/* First this one */

select * from musik.test where filnavn like '%\Oriental Voyage\%'

stripped by parser >>

select * from musik.test where filnavn like '%Oriental Voyage\%'

evaluted by Mysql server >>

select * from musik.test where filnavn like '%Oriental Voyage%' /* O simply resolves to O and \ to (literal) */

/* finds all tracks in album */

/* This however: */

select * from musik.test where filnavn like '%\Oriental Voyage\%'

stripped by parser >>

select * from musik.test where filnavn like '%Oriental Voyage%'

evaluated by MySQL server >>

select * from musik.test where filnavn like '%Oriental Voyage%' /* trailing % is here LITERAL % and O simply resolves to O */

/* finds nothing since there is no literal instance of 'Oriental Voyage%'*/

/* And finally */

select * from musik.test where filename like 'M:\Music\%'

stripped by parser >>

select * from musik.test where filename like 'M:Music\%'

evaluated by mySQL server

select * from musik.test where filename like 'M:Music%' /* M simply resolves to M */

/* finds nothing since there is no literal instance of 'M:Music' */

[peterlaursen]

And it is something equivalent to EXACTLY one character that is at the end.

[Author]

Posts