Unsupported Screen Size: The viewport size is too small for the theme to render properly.

Forum Replies Created

Viewing 15 posts - 6,796 through 6,810 (of 7,398 total)
  • Author
    Posts
  • in reply to: New problem with SJA #18461
    peterlaursen
    Participant

    Just as I thought – the one missing was the one with this 'filnavn':

    M:Peters MusikAntologierRêves d'Oasis Desert Blues 2 (1 of 2)7 Gibran.mp3

    escaping problem with d'Oasis when 'filnavn' not PK ? ??

    NOTE: string d'Oasis occurs in more colums …

    in reply to: still problems with \ character in PK #18282
    peterlaursen
    Participant

    I'll try rewrite it some way then:

    transferred to my term “evaluation order” (with “evaluation order” I mean in logical terms. Code design may differ from that) that would mean:

    1)

    Evaluated first: SQL_WHERE. Selects rows that should be considered further in the proces. SQL_WHERE is executed on both hosts (what I think it should not with a one-way sync!) and any row on either of the hosts that fullfills the where-condition (and ONLY those rows) proceeds to next step

    2)

    Evaluated next: PK's of the rows selected with step 1).

    If a row selected with 1) has a PK-value that exists on source only that implies insertion on target.

    If a row selected with 1) has a PK-value that exists on target only that

    … with a one-way sync: implies EITHER deletion on target OR no_action_taken (depending on whether “never delete” – option is set)

    … with a two-way sync: implies insertion on source.

    If a row selected with 1) has a PK-value that exists on both hosts that means: proceed to step 3.

    3) Evaluated last: With rows that has got as far as here checksums are calculated with the selected columns on both hosts. If checksums are identical nothing is done – if checksums not identical source_overwrites_target OR no_action_taken (depending on whether “never delete” – option is set)

    This I must consider this a “popular” description

    Quote:
    Since checksum generation is a CPU intensive work, you can skip BLOB columns if possible.

    That's trivial to me and you should know! It is not a matter of what to skip but what to choose (or put another way: not a matter of WHAT NOT TO DO but WHAT TO DO)!

    Couldn't you show it ALL with some diagram ?? (If you can't you haven't understood either! 😛 )

    So that we won't have to be fed with small bite's from time to time ? Try to think not as a developer but as a user 😀

    I really ask you to be VERY precise and detailed ….

    in reply to: Another memory-issue #18458
    peterlaursen
    Participant

    I just want to add that fixing this issue should not significantly delay release of neither 4.07 final or 4.1 (one big improvement does not need to await another!) – especially not 4.07 because I consider the “export-NULL” -bug in 4.06 to be critical.

    in reply to: still problems with \ character in PK #18280
    peterlaursen
    Participant

    1) Since it will ALWAYs use the PK-column(s) I don't see why I should need to specify it.

    2) In this case I ONLY want to use SQL_WHERE. SJA should generate checksums only on rows that satisfy the SQL_WHERE condition (besides using the PK as it must do).

    I don't find it logical.

    It's not at all a big deal – rather cosmetic, but anyway a little bit confusing, I believe.

    In my “White Paper” I wrote

    Quote:
    And what is the evalutation order of the PK and the and the SQL_WHERE conditions when they are all used? Or does that question make sense at all when put this way? If not how then to understand it ? Personally I am still a bit uncertain if I understand all aspects of it with the more complicated combinations of settings.

    This is an example …

    in reply to: still problems with \ character in PK #18278
    peterlaursen
    Participant

    The workaround in my case to repair this defect with the data imported from Access is to run this SQL after import (faster than export/import and can be automated I hope with the soon-coming Scheduled ODBC-import -feature of SQLyog I hope)

    Code:
    UPDATE mp3_filer SET filnavn = TRIM(trailing RIGHT(filnavn,1) FROM filnavn);

    .. just in case someone is still interested …

    in reply to: still problems with \ character in PK #18277
    peterlaursen
    Participant
    Quote:
    It wont make any difference as SJA will search for the primary key columns in the tables.

    The GUI functionality does not seem to know that! If NO colums are selected it displays this error msg. Choosing the PK-column (and that alone) works fine (with SQL_WHERE operating on another column)!

    in reply to: Testing with php 5.1 #18456
    peterlaursen
    Participant

    pic shows use with php 5.1.

    Note that it is not Apache.exe (and thus not the php-system) that uses this. It is SQLyog .exe!

    It occurs like that when data traffic over TCP has come to an end.

    Nothing like it appears when not using tunnelling.

    To reproduce simply click on checkbox “show all” with a reasonable big DB (remember to tunnel!), open Task Manager and a Network Monitoring program and watch things.

    in reply to: missing highlight/coloring in editor #18452
    peterlaursen
    Participant

    Problem is that you can have connections open to different MySQL-versions with different keyword-lists.

    Can SQLyog handle this ?

    Another solution would be using two different shades of blue for keywords as of the MySQL version actually used by the connection on the one hand and higher versions on the other. That would also warn users that they would run into problems using the same statement with later MySQL versions if they occasionally use a word that is a keyword with later versions.

    in reply to: Migrating a phpBB Forum #18428
    peterlaursen
    Participant

    @commandante:

    are you sure that your sql-dump is consistent with the source DB (that everything is there) ?

    in reply to: New export-bug #18441
    peterlaursen
    Participant

    I confirm that all export/import issues with 4.06 and 4.07 betas discussed here and here http://www.webyog.com/forums/index.php?act…t=ST&f=6&t=1504 are fixed.

    😀

    in reply to: Blob image viewer problems #18130
    peterlaursen
    Participant
    Quote:
    Only one image did the trick

    well – maybe you should have tried them all. It' s a lot better now, but still I experience that after inserting some 5-6 images the BLOB-viewer stop showing graphics. It is fixed when closing and restarting SQLyog. And the memoy management still does not impress me. But it has not crashed and no corruption of data has taken place with RC2.

    But try yourself one day to create a DB with 25 of those images and decide for yoursef if that's want you want from a professional program …

    I believe you still should improve on it over time …

    in reply to: Blob image viewer problems #18129
    peterlaursen
    Participant

    OK – I'll then shut down this outdated abacus of mine and go out to do some shopping for the weekend!

    in reply to: Blob image viewer problems #18127
    peterlaursen
    Participant

    Nice! and fine too that there is a logical explanation l! 😀

    That also explain my experience that if I inserted ONE image, saved and closed SQLyog, opened SQLyog inserted ONE image, saved, closed SQLyog, opened SQLyog and so on, then I could insert an unlimited number of images.

    BTW – if you liked my pic's there are more here http://www.deepeter.dk/Billedarkiv/Foretru…/Foretrukne.htm 😆

    in reply to: Blob image viewer problems #18125
    peterlaursen
    Participant

    http://deepeter.dyndns.dk/Bigpics/Bigpics.zip

    272 MB – not reduced as much as I thought it would be.

    have the “Bigzip” or the individual files as you like …

    in reply to: Blob image viewer problems #18124
    peterlaursen
    Participant

    Hold it – I'll zip them !!

Viewing 15 posts - 6,796 through 6,810 (of 7,398 total)