Forum Replies Created
-
AuthorPosts
-
Ritesh
MemberBug confirmed and fixed. Fix will be available from 4.07 RC2.
MemberCan you cut-n-paste the table sturcture?
It will be nice if you could zip and upload 6-7 of huge images on your server and give the link.
MemberQuote:The memory handling of SQLyog is not optimal for such big binary DATA.Sluggishness might happen for two reasons:
- SQLyog needs to get the complete image data as well as other result data to the client before we can display the image.
- The image library that we are using to display the images is taking time to implement/read the image.
MemberJust got a reply from the customer. He was not able to connect from his machine because Zone-Alarm was blocking SQLyog Enterprise.
MemberThis bug comes when you export resultset or table data?
MemberYes we will do.
We have tested the image library with the following image formats:
GIF, JPEG, PNG, TIFF, BMP, PCX
and it works great 😀
MemberQuote:When using the “columns” -option will it then make any difference whether you specify the PK-column(s) or not ??It wont make any difference as SJA will search for the primary key columns in the tables.
MemberQuote: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) !?
Yes, I changed the data and removed the extra .
The above issue is indeed important for sync. To get information about the different row in the source, SJA executes a SELECT * FROM … WHERE … query. Wiith the extra in the end, the query never returns the correct row of data and thus the changes are not done in the target.
MemberQuote:Right now I'm preparing a dataset for an extensive test with the -LIKE-PARSER caseI am eagerly waiting for the results.
MemberQuote: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 OKWhat is the size of the image?
A BLOB datatype has a limit of 64K. After that data is truncated by MySQL. Are you sure that image size is less then the datatype's max limit?
MemberSQLyog 4.07 BETA 4 is now SQLyog 4.07 RC1. Check out http://www.webyog.com/forums/index.php?act…st=0&#entry6181 for more details.
Memberpeterlaursen wrote on Jun 22 2005, 04:34 AM:This one should be better:there are now 17 rows in source, 14 in target.
Result with SJA:
Table SrcRows TgtRows Inserted Updated Deleted
========================= ======= ======= ======== ======= =======
`testsync2` 17 14 0 0 0
Total time taken – 1 sec(s)
Correct would be: 3 insert, 2 updates, 0 deletes
and still the same with an empty target: rows are inserted correctly.
Working closely with people from MySQL AB, we have been able to fix this issue. v4.07 BETA 4 which will be released tomorrow will have this bug fixed.
You can try the sync with data attached.
MemberThere was a bug with our image library that caused SQLyog to hang. We have fixed this issue.
We are now using a different image rendering library and starting from v4.07 BETA 4, you should be able to view images of GIF, JPEG, PNG, TIFF, BMP, PCX etc formats.
MemberAre you sure that your live server didnt have so many updation after the backup?
Many of customers like CalEvans have used it to backup/restore their data without any problem.
BTW: Have you tried our Data Sync Tool? A nice tutorial/article can be found at:
An addtional article on how to use it effectively can be found at http://www.webyog.com/forums/index.php?act…st=0&#entry6118
-
AuthorPosts
