Forum Replies Created
-
AuthorPosts
-
RiteshMember
We have better Indian food setup then India itself. The only thing I probably miss is the road side food.
RiteshMemberI think you should make Ctrl+1,2 etc. for query tab. I hardly concur if anybody even closes a window. Probably you can even put it in preference if you want backward compatibility but that would be too much work.
Sorry, a complete Linux and Mac setup here. Dont have any windows boxes for development!
RiteshMemberChange 95 to 98.
Get yourself an account in Wikipedia. Its very trivial to add/modify articles.
RiteshMemberWe use VS.NET 2003. Could you cut-paste the errors after trying it in 2003?
We are coming up a a “Developer's Guide” soon!
RiteshMember300K rows should not be a problem!
stom2005 is talking about 2 million rows, which might be a problem with virtual memory.
Are you sure that it is “hanging”? Maybe MySQL is taking time to return the result-set.
What is the table structure? How long have you waited?
RiteshMemberWe don't have a “known” bug of this nature?
How big is the table? What is the table structure? Does it have many large BLOB values?
What values are you providing in the limit fields?
RiteshMemberHave you considered creating the config. XML file manually?
RiteshMemberHello,
A couple of users have reported this issue, but we have not been able to duplicate this. It is happening in very rare cases.
The culprit is the Autocomplete feature. Turn it off and SQLyog will work fine.
Could you help us in duplicating the bug at our end? As a token of appreciation to your efforts, it will be our pleasure to give you a complimentary license of SQLyog Enterprise(with 1 year updates).
We would require the following info:
1) Version of SQLyog. Click Help->About
2) Version of Windows
3) What type of connection are you using – 1) Direct 2) HTTP tunnel 3) SSH Tunnel
4) Do you have admin access to your computer
5) Do you have stored procedures in your database?
6) Please send us a backup of the TAGS folder (located in c:program filesSQlyog Enterprise). It does not any personal info like user name / password. You can check the contents using a SQLite db GUI to make sure that so private data is being sent.
Finally, do you have an IM account/Skype a/c?
Looking forward to your reply!
If you dont want your information to be public, please create a ticket at Webyog Support
RiteshMemberWe will put that as a preference in the next release.
RiteshMemberLooks like an issue with your MySQL data or index. The error is returned by MySQL.
BTW, which version of MySQL are you using? It might be a known bug in that MySQL version.
RiteshMemberThere is no standard way to export/import USER information. The USER information are stored in tables in MySQL system DB.
You can very well export it and then import it at the target machine and issue the statement “FLUSH PRIVILEGES”. This is NOT RECOMMENDED though as you should not play around with data in the system tables.
June 16, 2006 at 7:21 am in reply to: Drag And Drop Reorder Tabs && Tabs Have Their Own Result Sets #21913RiteshMemberIf I correctly understand, you want the result tab to stick to the corresponding query tab.
Right now, the same result tab is being shared among all query tabs. So if you want to compare two result-sets side-by-side, you need to write multiple queries in the same query tab. Many users have requested that each query tab would have their “own” set of result tabs.
Am I correct?
RiteshMemberI think you are trying to establish HTTP/SSH Tunnel using the free version. Tunneling is not supported in the free version.
If you want to try out Tunneling, you can download the 30-day SQLyog Enterprise Trial from http://www.webyog.com/sqlyog/download_sqlyogent.html
HTH.
RiteshMemberpeterlaursen wrote on Jun 15 2006, 05:24 AM:I think you mean “In DATA tab …..”Yes 😀
RiteshMemberI think I understood the problem. It happens because we have a TIMESTAMP column with ON UPDATE CURRENT_TIMESTAMP in the table.
Now two timestamp will never be same for two tables and thus checksum will fail. As checksums fail to be similar, it deletes the ROWS from the target in the second parse. In this case all the rows are deleted.
To get around this issue as of now, dont select the TIMESTAMP column in checksum selection for the effected table.
We are working on a more elegant way to solve this issue but it will take some time.
-
AuthorPosts