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

Forum Replies Created

Viewing 15 posts - 5,716 through 5,730 (of 7,398 total)
  • Author
    Posts
  • in reply to: Repainting Issue #20837
    peterlaursen
    Participant

    I will check.

    Of course this is no big deal as things were readable.

    The reason why I posted it was to get some response if other users experienced the same.

    This was on a PC with a VIA on-board graphics chip. So maybe it affect only 'low-end' graphics systems like this.

    in reply to: Backup encoding problem #18477
    peterlaursen
    Participant

    Looks like SQLyog is using the LATIN1 ANSI encoding – even when that is not system default!

    I think learning about non-english localizations must be priority in Bangalore now! 😮

    in reply to: 1044 Error On Export As Sql Statment #20866
    peterlaursen
    Participant
    Quote:
    User Manager->Edit User returns the same error as above

    This is very usual. Most ISP's will only let you manage user privileges from their own 'Control Panel' application. But if you don't 'lock tables' I think you will only need SELECT privilege. However to flush-hosts, flush-logs, flush-privileges, flush-status, flush-tables, flush-threads, refresh & reload you must have RELOAD privilege as well. refer to http://dev.mysql.com/doc/refman/4.1/en/pri…s-provided.html

    But are they ordinary user tables that you try to backup? If it is some kind of system tables I doubt that they will let you

    If it is a DB used by a PHP application (such as a forums software, guestbook software etc.) you should be able to log on with SQLyog using the credentials of that PHP-script.

    Also:

    if you enable batch logging from 'preferences' you should be able to see in HISTORY what was the last (unsuccessfull) command sent by SQLyog.

    in reply to: 1044 Error On Export As Sql Statment #20864
    peterlaursen
    Participant

    Most likely it is a privilege issue with 'Lock tables' or 'Flush log'.

    What is your MySQL version? the LOCK_TABLE privilege was added recently and maybe user does not have it. And 'flush logs' is for use with replication primarily (and user must have replication related privileges) – though you may have a binary log also without replication.

    Try fill-out the dialogue as attached


    @Ritesh
    I request that program default will be to uncheck 'lock tables' . I think this is 3rd time we have this issue since MySQL added the LOCK_TABLE privilege

    in reply to: 5.1 Beta 2 Crashed Because Of Buffer Overrun #20859
    peterlaursen
    Participant

    The amount of data (# of rows, file sizes) is irrelevant. It is only the number of database objects that matters.

    Of course this should be fixed. But my point is that you don't need to specify all databases with one connection. Actually it is a good security procedure only to specify those that you need with each connection.

    Did you try if SQLyog could edit the .db-file at runtime on that server by adding or renaming a table?

    in reply to: 5.1 Beta 2 Crashed Because Of Buffer Overrun #20857
    peterlaursen
    Participant
    Quote:
    Now SQLyog just disappears quickly without any messages.

    But if you delete/rename the .db file, you probably will be able to rebuild it – from startup or from powertools menu?

    Also any change that SQLyog does to your MySQL database that relects the SQLite database (such as adding/renaming a table) will be saved by SQLyog. Only if ANOTHER CLIENT has modified the database you'll have to rebuild!

    Can you verify that? Add a small table, close SQLyog, restart SQLyog and the table just add should be available with TAB key. Or maybe changing the .db-file from inside SQLyog cases some error too when it is that big?

    But of course this is a bug of some kind. Program should not just disappear! I wonder if it is the CHECKSUMs introduced with BETA2 that runs over! CHECKSUMs were introduced to make 'rebuild tags' faster, when there was a partically complete and correct .db-file allready! I don't know which variable type is used for storing the CHECKSUM and what limitations it has!

    But no program should not crash like this.

    in reply to: 5.1 Beta 2 Crashed Because Of Buffer Overrun #20854
    peterlaursen
    Participant
    Quote:
    and sometimes I can hardly type so I prefer to switch it off

    You won't have to disable autocomplete completely. Only disable tooltips and you can still use TAB, CTRL+SPACE and CTRL+ENTER.

    did you read http://www.webyog.com/forums/index.php?sho…st=0&#entry9079

    But as I wrote before here .. maybe some of us (including me) should change our habbits a little to get the full advantage of autocomplete. Instead of having one of connection with a lot of database, we could have more connections!

    in reply to: 5.1 Beta 2 Crashed Because Of Buffer Overrun #20852
    peterlaursen
    Participant

    this is stuff for Ritesh to study! But undoubtedly the is an issue with such amount of data to be cached by SQLyog after rebuild. If SQLite Browser opens the file, the file probably is OK ifself.

    Two questions more:

    1) does autocomplete work OK with that big .db-file? (if you start without rebuild?)

    2) what happens if you start rebuild manually (from 'powertools' ?)

    in reply to: 5.1 Beta 2 Crashed Because Of Buffer Overrun #20850
    peterlaursen
    Participant
    Quote:
    So I had four connections to four different servers and only one works.

    SQLyog disappears very quickly as soon as I try to connect to the remaining three.

    Then I have deleted a .db file from the Tags folder… and – good news – was able to connect to all servers

    but – bad news – only as long as tag file building was in process. After them, SQLyog was gone again.

    Well … I cannot tell if this buffer is the internal SQLite buffer or if it is some other buffer that SQLyog uses to cache the DB information. Most likely the latter – but just a guess!

    in reply to: 5.1 Beta 2 Crashed Because Of Buffer Overrun #20848
    peterlaursen
    Participant

    BTW …

    I moved to the category *BETA discussions*

    in reply to: 5.1 Beta 2 Crashed Because Of Buffer Overrun #20847
    peterlaursen
    Participant

    @vygi

    Do you have a lot of databases with a lot of tables with a lot of columns in that connection?

    Do you find the .tag file for the connection in TAGS directory and does it look valid? You can open it with SQLite Query Browser fron here: http://sqlitebrowser.sourceforge.net/

    Also now that the tag file has been built can you open it next time you start SQLyog without a crash?

    Could you try selecting only a single small database with a connction and open that connection?

    SQLite has an option to send a PRAGMA statement allokating a memory buffer for its use. Maybe SQLyog should test for the size of memory buffer that it needs and send that PRAGMA statement.

    And how big is that TAG-file?

    and @ritesh – actually I have a question too. See the screenshot of my TAGS-folder. There are quite a lot of ZERO-size .db files with cryptical names. What are they? I think it is new with BETA2 – I don't remember this with BETA1.

    in reply to: Export Procedures #20846
    peterlaursen
    Participant

    Let me add the the DELIMITER is nothing that the MySQL server will ever know about. DELIMITER is implemented in the CLIENT only. No DELIMITER command will ever reach the SERVER (and if it did, it would cause an error!).

    So clients may implement support for this in thousands of different ways. It could be a completely graphical implementation that does not involve the word 'DELIMITER' at all (a coloring, a typography for instance)! The only thing we'll need is to find a way to describe if a statement seperator like “;” seperates INSIDE A STORED PROCEDURE CREATE-statement, or if it seperates SQL-STATEMENTS.

    in reply to: Export Procedures #20845
    peterlaursen
    Participant

    Please read http://www.webyog.com/faq/26_49_en.html

    What is WRONG and RIGHT here ? There are no standards, I believe!

    Can't you import with SQLyog?

    SQLyog does not claim to be compatible with Mysqldump in this respect!

    in reply to: Create Table Generated Query Error #20843
    peterlaursen
    Participant

    Looks to me like a truncation taking place because of a buffer variable being too short!

    in reply to: Create Table Generated Query Error #20842
    peterlaursen
    Participant

    Looks like this happens with CREATE TABLE only – I cannot trigger this bug with ALTER TABLE or CHANGE TABLETYPE.

Viewing 15 posts - 5,716 through 5,730 (of 7,398 total)