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

Forum Replies Created

Viewing 15 posts - 5,806 through 5,820 (of 7,398 total)
  • Author
    Posts
  • in reply to: Postgresql Support Expected? #20728
    peterlaursen
    Participant
    Quote:
    If the company had more resources …

    Exactly! But as of now the ABSOLUTE 1st priority is complete unicode support in Data Management and Program's Appearance. Also a cross-platform release (native Windoes, Linux and Mac-OS-X) is higher priority than support for other databases.

    resources >> read: revenue! There is no 'piling up' of money here. Every dime earned goes into to continued development! The more people that buy, the faster development. There is no problems in getting qualified people for the office in Bangalore!

    in reply to: Postgresql Support Expected? #20726
    peterlaursen
    Participant

    A personal comment.

    I don't know very much about Postgresql. But I do think I know that the internal structures (for handling of METADATA especially) of MySQL and PostgreSQl are very different. I think it will be very difficult to support both from identical GUIs.

    in reply to: Autocomplete Very Slow #20699
    peterlaursen
    Participant

    Then it would be very nice if the setting 'rebuild at startup' was connection-specific!

    When some day the connection settings are moved from .ini to .db file there are quite a lot of settings that could be connections-specific.

    in reply to: Long Wait On Refresh Of Database With Many Tables #20604
    peterlaursen
    Participant
    Quote:
    If SHOW TABLES is really faster than SELECTing from INFORMATION_SCHEMA, we might give the user an option to continue using SHOW TABLES.

    That would also indirectly give users an option to display VIEWs along with TABLES. Some might prefer this. Maybe even I in some situations. If this option could be connection-specific it would be just fine!

    in reply to: Long Wait On Refresh Of Database With Many Tables #20603
    peterlaursen
    Participant

    @ritesh

    What part of your anatomy are you using for reading? 😛

    Was exactly what I wrote I guess!

    Code:
    Those are created at connection:

    /*[8:09:22 AM][ 94 ms]*/ show variables like '%character%'
    /*[8:09:22 AM][ 62 ms]*/ Set character_set_connection=latin1
    /*[8:09:22 AM][ 47 ms]*/ Set character_set_results=latin1
    /*[8:09:22 AM][ 63 ms]*/ Set character_set_client=latin1
    /*[8:09:22 AM][ 46 ms]*/ set sql_mode=''

    in reply to: Postgresql Support Expected? #20725
    peterlaursen
    Participant

    The official statement in the FAQ:

    http://www.webyog.com/faq/32_65_en.html

    in reply to: Autocomplete Very Slow #20697
    peterlaursen
    Participant

    Ok … 😀

    That means then that if SQLyog is the only client used that does changes to MySQL databases, then there should in principle be no need to rebuild at all (except for repair) ?

    in reply to: Autocomplete Very Slow #20695
    peterlaursen
    Participant

    Or maybe even better: simply insert/update/drop a row to embedded database 'on the fly' when CREATE, ALTER, DROP and RENAME has been executed by mysql.

    I know this is quite a new thing – MySQL statements will have to be parsed as it is not only SQL executed from GUI objects but also from SQL-pane. Looking back I think that is how it should have been in the first place.

    But still this is not iliask's issue – his is a runtime issue with the editor pane an the keyboard.

    in reply to: Autocomplete Very Slow #20694
    peterlaursen
    Participant

    I overlooked that prefrences had changed a little with first public BETA.

    I request then a 'save changes to tag file' option when closing program like editor has). Actually I think I would prefer NOT to rebuild at startup, but I would like to save changes that I made when I close. I think that could be made very faster if there was a HISTORY the of embedded database. Won't have to rebuild everything then but only exectue the changes of the session.

    Actually it is only CREATE, ALTER, DROP and RENAME SQL that must be executed with SQLite, I believe.

    in reply to: Autocomplete Very Slow #20693
    peterlaursen
    Participant

    I don't think Iliask is talking about build-time here. I understand that his keyboard becomes kind of non-responsive at run-time.

    As I wrote I think the size of the connection-specific database and the relative performance of RAM and CPU might do this. I you buy a 'monster' of a MB with 1000 Mhz RAM (DDR2 Hyperchannel or similar technology) and equip it with an older slow processor.

    There are some settings with the OS where you can give relative priority to applications (sqlyog) and system (keyboard).

    in reply to: Autocomplete Very Slow #20690
    peterlaursen
    Participant

    On this 1 Ghz computer of mine (the slowest that I have) typing 'mys' displays a small pop-up 'mysql – press TAB to insert'. From I type the 's' to the popup appears a splitsecond later SQLyog proces takes around 30% of available CPU resources according to Task Manager. Similar with other autocomplete features.

    Now I figure that when CPU does not go higher here it was be because RAM access is the bottleneck on this system. It is DDR266 RAM. Maybe you have a 'monster' with for instance DDR2 RAM so that CPU-resources become the bottleneck?

    I think that some of us (including me) could change our habits when using auto-complete. Instead of having ONE CONNECTION ONLY with all databases on a host, we could consider having MORE CONNECTIONS each with the databases that we need for particular tasks.

    The most important optimization isssue for me with auto-complete is reduced disk-access at startup!

    in reply to: Autocomplete Very Slow #20689
    peterlaursen
    Participant
    Quote:
    Also, you can disable building of tag files on each start up using Tools->Preferences

    But that would COMPLETELY disable auto-complete wouldn't it?

    in reply to: Autocomplete Very Slow #20687
    peterlaursen
    Participant
    Quote:
    Autocomplete seriously slows down writting of queries as it freezes the editor

    On a 1 Ghz computer here I have this kind of 'feeling' too in very low degree if no other demanding task is running. However I think, that you should just type on. Keystrokes should be saved in the keyborard buffer. What happens if you just hold down a key like 'aaaaaaaaaaaaaaaaaa'? I think Ritesh told me that the SQLite was running in it own thread. Could Ritesh comment on it?

    Quote:
    you could use the Data_length or Checksum of a table to make a decision …

    Good idea! Provided that it is possible to generate identical checksums of MySQL and SQLite database tables.

    in reply to: Data Synch Complains But Can't See Why #20709
    peterlaursen
    Participant

    Are MySQL versions identical?

    Older SJA-versions would display this message if not.

    The most recent versions should display an error msg.

    http://www.webyog.com/faq/category11.html

    in reply to: Odd Effect Copying Table, 0 Values In Primary Key #20710
    peterlaursen
    Participant

    With MySQL 5 the sql_mode can be changed. You can do from SQL pane:

    http://www.webyog.com/faq/index.php?action…hlight=sql_mode

    it is not a 'server mode' from 4.1 is a connection specific mode – and changeable from 5.0

    Quote:
    the “0” value in the first row is being interpreted as NULL

    I don't think this is the explanation. If it was it was a regular BUG with MySQL.

Viewing 15 posts - 5,806 through 5,820 (of 7,398 total)