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

Forum Replies Created

Viewing 15 posts - 5,866 through 5,880 (of 7,398 total)
  • Author
    Posts
  • in reply to: Download/sync With Odbc #20646
    peterlaursen
    Participant
    Quote:
    Is this planned?

    Let us say it is being considered!

    We need to implement two more features with the option to do this.

    1) the delete-trigger type should remove 'orphaned' rows in the ODBC-source

    2) the update-trigger type should query MySQL and the fetch the values to update with.

    Agree it would be nice! And I think it could be done with most ODBC-drivers. Not the ODBC-text-driver and I believe dBase and similar 'early' ODBC implementations would have problems too.

    in reply to: Syncronization Case Sensitivity #20586
    peterlaursen
    Participant

    to be specific:

    If 'lower_case_table_names' is '1' or '2' on both servers sync should be case insensitive

    If 'lower_case_table_names' is '0' on both servers sync should be case sensitive

    If 'lower_case_table_names' is '0' on one server and '1' or '2' on the other sync should be case sensitive as default. However if there is no conflict a popup could display offering to do the sync anyway. And to avoid server errors the name-CASE of the table on the server where it is case sensitive should be use.

    This applies to STRUCTURE SYNC and DATA SYNC as well.

    Did I get it all? 😮

    in reply to: Syncronization Case Sensitivity #20585
    peterlaursen
    Participant
    in reply to: Syncronization Case Sensitivity #20584
    peterlaursen
    Participant

    we are a lot of 'former's 🙂

    But you are missing an important point:

    Case sensivity with *NIX and Non-case sensivity with Windows (and sometimes MAC, depending on the filesystem on which it is installed) are only DEFAULTs for the systems. The behaviour can be changed with the 'lower_case_table_names' system variable on all platforms.

    So where appropriate SQLyog should query this system variable and adjust its CASE SENSIVITY accordingly!

    in reply to: Export Views #20231
    peterlaursen
    Participant

    @ritesh:

    When is monday?

    Monday February 19th 2007 ? 😛

    I checked SQLyog 5.1 beta1. Seems to work fine now. No table is created and then dropped. However a small cosmetics:

    The

    Code:
    drop view if exists …

    is repeated twice for each view.

    in reply to: Export Issue #20641
    peterlaursen
    Participant

    One more question:

    Do you generate BULK INSERT statements?

    If so the BULK SIZE will be as big as the max_allowed_packet setting of the MySQL server. That might be too much for PHP with the current cofiguration!

    Ritesh has promised me that BULK size wll be made user configurable in near future (no later than SQLyog 5.2).

    in reply to: Export Issue #20640
    peterlaursen
    Participant

    Also ..

    do you use the 'ordinary' export option or the 'powertool' backup option of SQLyog Enterprise?

    If 1st is the case, you my try the latter (demo available if you don't have Enterprise)

    EDIT: Of course you have Enterprise since you are able to tunnel!. Silly remark from me! 😎

    in reply to: Export Issue #20639
    peterlaursen
    Participant

    This

    Quote:
    MySQL client run out of memory

    now .. in this case is the MySQL client the SQLyog program or the PHP binary? I am not sure!

    Do you have access to php configuration?

    in reply to: Column Defaults #20611
    peterlaursen
    Participant

    Correction:

    it should write simply

    Code:
    insert into `testtable` (`mytext`) values ('d')

    I don't believe you will ever make this work unless you understand that COLUMN DEFAULTS should handled by the server and not the client. Simply skip empty cells when generating an INSERT or UPDATE statement as you allready do with TIMESTAMPs defined as 'on update CURRENT_TIMESTAMP' when there are data in them.

    In NON-STRICT mode as used by SQLyog connections this will never generate an error.

    in reply to: Howto Rename Database… #20543
    peterlaursen
    Participant
    Quote:
    as soon as an alpha release of 5.1.8 is released

    MySQL 5.1.7 will be released as BETA as I understand, so 5.1.8 probably too 😀

    Actually 5.1 is comming fast – much faster than 5.0. I think it is final before the end of the year!

    in reply to: Turkish Characters #20381
    peterlaursen
    Participant

    I can insert Danish characters into a BLOB column using HTTP with no problem.

    But not into a TEXT or VARCHAR. This is true for PHP 4.4.2 and 5.1.2 on my locals and for 4.4.2 on my own webhost.

    But on a server running PHP 4.3.2 (you know which one!) I can HTTP-write æøåÆØÅäöüëéñ etc in BLOB, TEXT and VARCHAR columns as well.


    @ritesh

    doesn't that (that BLOB write and TEXT and VARCHARS don't) more or less prove that it is not an issue with SQLyog?

    I really start to suspect that the latest PHP builds are buggy – or the connectors distributed by MySQL!

    in reply to: Turkish Characters #20380
    peterlaursen
    Participant

    Now this is very very interesting:

    http://bugs.mysql.com/bug.php?id=17458

    However my HTTP-write problem occurs also with MySQL 4.0 and tested same with php 442 and 512.

    But no matter what this thread is worth bookmarking!

    in reply to: Syncronization Case Sensitivity #20582
    peterlaursen
    Participant
    Quote:
    If sync'ing a LINUX server with a Windows server (with their default settings)? …  But the SJA SCHEMA can't handle this as of now. Right?

    Wrong actually I believe after thinking a little! If the jobfile uses the table-names of the Unix-machine, it should work!

    in reply to: Syncronization Case Sensitivity #20581
    peterlaursen
    Participant

    also:

    it should not be either case-sensitive or case-insentensive – it should be both! And adjust according to the 'lower_case_table_names' settings of the server(s).

    Now (an these questions apply to STRUCT SYNC and DATA SYNC as well):

    If two servers have different settings – what then?

    If sync'ing a LINUX server with a Windows server (with their default settings)?

    I see no other option than an additional popup to ask user what to do if things are ambigious. But the SJA SCHEMA can't handle this as of now. Right? How to data sync TABLE on Windows with table on Unix?

    in reply to: Syncronization Case Sensitivity #20580
    peterlaursen
    Participant

    @ritesh

    DATA SYNC also has problems. With my example it should not even attempt to sync! Tables are different. There are no tables to sync. But it sees them as identical. However the the server does not agree (!) and thus the error.

    This is an error in SQLyog.exe. That does not exclude errors in sja.exe!

    Also – if you run a MIGRATION, BACKUP, or NOTIFY job and connect to a DB with a table and a TABLE – are you sure that it tries to read from/write to the right table? It should be checked! Though it could very well be that it affect only tools involving two MySQL datases with the task/job.

Viewing 15 posts - 5,866 through 5,880 (of 7,398 total)