sql-buddy - Project Hosting on Google Code

Older Nov 15, 2009 issue 18 (White page after login) commented on by IM.Hanz - My issue was that mysql.so was disabled. Any reason we can't use mysqli.so instead? (I also have issues with gzip, although I am sure this will be fixable with a little playing around) My issue was that mysql.so was disabled. Any reason we can't use mysqli.so instead? (I also have issues with gzip, although I am sure this will be fixable with a little playing around) Nov 15, 2009 issue 18 (White page after login) commented on by IM.Hanz - I have exactly the same issue. Web server: nginx and PHP: PHP 5.3.0 with Suhosin-Patch (cli) (built: Sep 27 2009 22:01:22) I have exactly the same issue. Web server: nginx and PHP: PHP 5.3.0 with Suhosin-Patch (cli) (built: Sep 27 2009 22:01:22) Oct 22, 2009 issue 24 (Ajax edit-in-place) commented on by Yonas.Y - Btw, thanks for getting back to this :) Btw, thanks for getting back to this :) Oct 22, 2009 issue 24 (Ajax edit-in-place) commented on by Yonas.Y - Where do you see the complexity coming from? I frequently do AJAX coding, and it's not that complicated. Where do you see the complexity coming from? I frequently do AJAX coding, and it's not that complicated. Oct 22, 2009 issue 24 (Ajax edit-in-place) Status changed by calvinlough - I have considered it in the past, but have always thought that the added complexity wouldn't be worth it. Status: Invalid I have considered it in the past, but have always thought that the added complexity wouldn't be worth it. Status: Invalid Oct 22, 2009 issue 27 (Cannot manage users on a remote database server) Status changed by calvinlough - Thanks for reporting this. I will make the change in the repo. Status: Accepted Thanks for reporting this. I will make the change in the repo. Status: Accepted Oct 18, 2009 issue 27 (Cannot manage users on a remote database server) reported by brian.cline - What steps will reproduce the problem? 1. Install Apache and MySQL on separate boxes, and SQL Buddy on the Apache box. 2. Create a user in MySQL with full privileges with a host or IP of the Apache box. 3. Log in with SQL Buddy and navigate to the Users screen. What is the expected output? What do you see instead? Expected output is the full user management console. Instead, I see a list of existing users but the bottom panel says "You do not have enough permissions to create new users." What version of the product are you using? On what operating system? The latest version from the web site (cannot find any screens in SQL Buddy that mention the current version number - this probably ought to be added to the home screen somewhere). Running on CentOS 5.3, PHP 5.3.0, MySQL 5.1.39. Please provide any additional information below. It appears that SQL Buddy is querying the mysql.users table by logged-in user name and database server name to check permissions, rather than using the user name and local server name for which a grant was created. So, for example, my web server ads-web-01 runs SQL Buddy to connect to ads-db-01. SQL Buddy is looking in the users table for a record for sqlbuddy@ads-db-01, when it should be looking for sqlbuddy@ads-web-01. I've been able to work around this bug by modifying the query at users.php:440 to read thusly: $checkSql = $conn->query("SELECT `Grant_priv` FROM `user` WHERE `Host`=(SELECT SUBSTRING_INDEX(USER(), '@', -1)) AND `User`=(SELECT SUBSTRING_INDEX(USER(), '@', 1)) LIMIT 1"); This takes advantage of the built-in MySQL function USER(), which returns the current user name and originating hostname in a single-column result (i.e., 'sqlbuddy@ads-web-01.domain.com'). After applying this fix, user management still appears to work fine when connecting to a local MySQL instance, as USER() returns 'sqlbuddy@localhost'. So if you were to make the same fix to the repo, then the majority of your users ought not notice any difference as I imagine most of them run MySQL and SQL Buddy on the same machine. What steps will reproduce the problem? 1. Install Apache and MySQL on separate boxes, and SQL Buddy on the Apache box. 2. Create a user in MySQL with full privileges with a host or IP of the Apache box. 3. Log in with SQL Buddy and navigate to the Users screen. What is the expected output? What do you see instead? Expected output is the full user management console. Instead, I see a list of existing users but the bottom panel says "You do not have enough permissions to create new users." What version of the product are you using? On what operating system? The latest version from the web site (cannot find any screens in SQL Buddy that mention the current version number - this probably ought to be added to the home screen somewhere). Running on CentOS 5.3, PHP 5.3.0, MySQL 5.1.39. Please provide any additional information below. It appears that SQL Buddy is querying the mysql.users table by logged-in user name and database server name to check permissions, rather than using the user name and local server name for which a grant was created. So, for example, my web server ads-web-01 runs SQL Buddy to connect to ads-db-01. SQL Buddy is looking in the users table for a record for sqlbuddy@ads-db-01, when it should be looking for sqlbuddy@ads-web-01. I've been able to work around this bug by modifying the query at users.php:440 to read thusly: $checkSql = $conn->query("SELECT `Grant_priv` FROM `user` WHERE `Host`=(SELECT SUBSTRING_INDEX(USER(), '@', -1)) AND `User`=(SELECT SUBSTRING_INDEX(USER(), '@', 1)) LIMIT 1"); This takes advantage of the built-in MySQL function USER(), which returns the current user name and originating hostname in a single-column result (i.e., 'sqlbuddy@ads-web-01.domain.com'). After applying this fix, user management still appears to work fine when connecting to a local MySQL instance, as USER() returns 'sqlbuddy@localhost'. So if you were to make the same fix to the repo, then the majority of your users ought not notice any difference as I imagine most of them run MySQL and SQL Buddy on the same machine. Aug 14, 2009 r55 (Getting ready for release: small doc changes, etc.) committed by calvinlough - Getting ready for release: small doc changes, etc. Getting ready for release: small doc changes, etc. Aug 03, 2009 r54 (Proper exporting of auto_increment values) committed by calvinlough - Proper exporting of auto_increment values Proper exporting of auto_increment values Jul 08, 2009 issue 23 (Connection to a non-standard port) commented on by fabian.beiner - Maybe give the added patch a try. I guess it should work, I didnt test it heavily, too. It just adds a "port" field to the login.php file. Maybe give the added patch a try. I guess it should work, I didnt test it heavily, too. It just adds a "port" field to the login.php file. Jul 05, 2009 issue 6 ('Save to file' option is buggy) commented on by scott.vivian - You can solve this by making the "exports" directory writeable (CHMOD to 777). However, the message isn't helpful and it's unclear what file is "being opened" - i.e. where SB is trying to save files to. This method of writing SQL to a file on the filesystem for download is not very convenient IMO and is a security risk (anyone could type yourdomain.com/sqlbuddy/exports/export.sql into their browser and find the data if you don't go into the FTP and manually delete it). A better solution would be to serve up the file for instant download, bypassing the need for local storage. You can solve this by making the "exports" directory writeable (CHMOD to 777). However, the message isn't helpful and it's unclear what file is "being opened" - i.e. where SB is trying to save files to. This method of writing SQL to a file on the filesystem for download is not very convenient IMO and is a security risk (anyone could type yourdomain.com/sqlbuddy/exports/export.sql into their browser and find the data if you don't go into the FTP and manually delete it). A better solution would be to serve up the file for instant download, bypassing the need for local storage. Jul 05, 2009 issue 26 (Extremely long queries (exported from SB) do not run) commented on by scott.vivian - After a little more investigation, it appears that SQL Buddy is ignoring any query over ~32 kB (~32,000 characters I suppose). I manually added "INSERT INTO" lines to my SQL files that came from SB, one every 40 lines. Semicolons are in the right places. On the first attempt at importing, 320 rows were added to the database, but SB flunked on the next set of lines (without this section, it inserted all other rows). I also tested this and similar queries in separate files - at about the 32kB mark SB starts ignoring the file totally. Under this, SB either inserts the data as normal or tells me that there is a problem (e.g. duplicate key). Side note: it would be useful if SQL Buddy provided some better error messages across the app! After a little more investigation, it appears that SQL Buddy is ignoring any query over ~32 kB (~32,000 characters I suppose). I manually added "INSERT INTO" lines to my SQL files that came from SB, one every 40 lines. Semicolons are in the right places. On the first attempt at importing, 320 rows were added to the database, but SB flunked on the next set of lines (without this section, it inserted all other rows). I also tested this and similar queries in separate files - at about the 32kB mark SB starts ignoring the file totally. Under this, SB either inserts the data as normal or tells me that there is a problem (e.g. duplicate key). Side note: it would be useful if SQL Buddy provided some better error messages across the app! Jul 05, 2009 issue 26 (Extremely long queries (exported from SB) do not run) reported by scott.vivian - What steps will reproduce the problem? 1. Create a table with 400 rows (total data size is around 200 kB). 2. Export using SQL Buddy. 3. Import using SQL Buddy (e.g. into another database). What is the expected output? What do you see instead? I expect all queries to be imported. What version of the product are you using? On what operating system? SB 1.3.1 Apache 2.0 PHP version 5.2.6-3ubuntu4.1 MySQL 5.0.75 Please provide any additional information below. I believe the issue is due to the fact that when exporting, there is actually only one query in the file (when using "Compact inserts"). You have an "INSERT INTO" line, followed by 400 lines of data. When exporting SB should split compact inserts into groups of 50 or so (as phpMyAdmin does). In other words, one "INSERT INTO" line, then 50 data lines, semicolon, another "INSERT INTO" line, 50 data lines, etc etc. What steps will reproduce the problem? 1. Create a table with 400 rows (total data size is around 200 kB). 2. Export using SQL Buddy. 3. Import using SQL Buddy (e.g. into another database). What is the expected output? What do you see instead? I expect all queries to be imported. What version of the product are you using? On what operating system? SB 1.3.1 Apache 2.0 PHP version 5.2.6-3ubuntu4.1 MySQL 5.0.75 Please provide any additional information below. I believe the issue is due to the fact that when exporting, there is actually only one query in the file (when using "Compact inserts"). You have an "INSERT INTO" line, followed by 400 lines of data. When exporting SB should split compact inserts into groups of 50 or so (as phpMyAdmin does). In other words, one "INSERT INTO" line, then 50 data lines, semicolon, another "INSERT INTO" line, 50 data lines, etc etc. Jul 05, 2009 issue 17 (Set the width of tables dynamically) commented on by scott.vivian - +1 for this. Numeric and date fields are several times larger than they need to be. I've also noticed a related issue: on long text fields, the text is truncated to 66 characters (weird number) with [...] after it. However, this is rarely visible, because the column width is too small for those fields. Am I right in thinking the problem occurs because of the table header? It looks like it's not part of the data table itself, meaning you can't rely on auto column widths. Not sure if there is a clear fix for that, aside from always using one table. +1 for this. Numeric and date fields are several times larger than they need to be. I've also noticed a related issue: on long text fields, the text is truncated to 66 characters (weird number) with [...] after it. However, this is rarely visible, because the column width is too small for those fields. Am I right in thinking the problem occurs because of the table header? It looks like it's not part of the data table itself, meaning you can't rely on auto column widths. Not sure if there is a clear fix for that, aside from always using one table. Jul 05, 2009 issue 25 (Counting error when importing file) reported by scott.vivian - What steps will reproduce the problem? 1. Import a file with 1 or more insert statement in it. The text "0 statements were executed from the file" is displayed, but some entries WERE imported. The number next to "Browse (n)" in the top navigation increases to the correct number of rows in the table. Using v1.3.1 (latest), same issue happens on a Linux server and on Windows with WampServer. What steps will reproduce the problem? 1. Import a file with 1 or more insert statement in it. The text "0 statements were executed from the file" is displayed, but some entries WERE imported. The number next to "Browse (n)" in the top navigation increases to the correct number of rows in the table. Using v1.3.1 (latest), same issue happens on a Linux server and on Windows with WampServer. Jun 19, 2009 issue 18 (White page after login) commented on by Aqua32 - Found the problem. Partially SQLBuddys fault - partially mine. took every @ from all sql command in sql.php so that I could actually see the error. You should not put @ before commands like this but instead tell people to set display_errors=Off in php.ini Either that or have a setting where a conditional @mysql_connect or mysql_connect command is executed depending on debug mode. apt-get install php5-mysql solved the problem :-) lol. Found the problem. Partially SQLBuddys fault - partially mine. took every @ from all sql command in sql.php so that I could actually see the error. You should not put @ before commands like this but instead tell people to set display_errors=Off in php.ini Either that or have a setting where a conditional @mysql_connect or mysql_connect command is executed depending on debug mode. apt-get install php5-mysql solved the problem :-) lol. Jun 19, 2009 issue 18 (White page after login) commented on by Aqua32 - Incidentally, my lighttpd log file shows and HTTP 500: [19/Jun/2009:22:36:39 -0400] "POST /sqlbuddy/login.php HTTP/1.1" 500 It the login.php chokes here: $connCheck = new SQL($connString, $user, $pass); Incidentally, my lighttpd log file shows and HTTP 500: [19/Jun/2009:22:36:39 -0400] "POST /sqlbuddy/login.php HTTP/1.1" 500 It the login.php chokes here: $connCheck = new SQL($connString, $user, $pass); Jun 19, 2009 issue 18 (White page after login) commented on by Aqua32 - Incidentally, my lighttpd log file shows and HTTP 500: [19/Jun/2009:22:36:39 -0400] "POST /sqlbuddy/login.php HTTP/1.1" 500 sqlbuddy is writing something incorrectly. Incidentally, my lighttpd log file shows and HTTP 500: [19/Jun/2009:22:36:39 -0400] "POST /sqlbuddy/login.php HTTP/1.1" 500 sqlbuddy is writing something incorrectly. Jun 19, 2009 issue 18 (White page after login) commented on by Aqua32 - I have this issue, also. Running Lighttpd / MySQL5 I have this issue, also. Running Lighttpd / MySQL5 Jun 15, 2009 issue 22 (Auto Increment columns are not displayed or exported properl...) Status changed by calvinlough - This will be fixed in 1.3.2. Thanks for reporting it. Status: Fixed This will be fixed in 1.3.2. Thanks for reporting it. Status: Fixed May 20, 2009 issue 24 (Ajax edit-in-place) reported by Yonas.Y - Feature request: It would be nice to be able to edit fields in place using Ajax instead of being redirected to another page. This feature was also request for phpMyAdmin: http://sourceforge.net/mailarchive/message.php?msg_id=E1H8B0m-0006PW-0c%40sc8-sf-web7.sourceforge.net The code for edit-in-place can be found on the net, and in JS frameworks like jQuery/prototype/script.aculo.us/etc. Cheers, Yonas Feature request: It would be nice to be able to edit fields in place using Ajax instead of being redirected to another page. This feature was also request for phpMyAdmin: http://sourceforge.net/mailarchive/message.php?msg_id=E1H8B0m-0006PW-0c%40sc8-sf-web7.sourceforge.net The code for edit-in-place can be found on the net, and in JS frameworks like jQuery/prototype/script.aculo.us/etc. Cheers, Yonas Apr 15, 2009 r53 (auto_increment (and other values) are now properly exported ...) committed by calvinlough - auto_increment (and other values) are now properly exported (they were before, but a breaking change occurred at some point). auto_increment (and other values) are now properly exported (they were before, but a breaking change occurred at some point). Apr 15, 2009 issue 23 (Connection to a non-standard port) reported by ether.knight - What steps will reproduce the problem? 1. Configure MySQL to use a non-standard port, i.e 3307 2. Install (unzip) sqlbuddy to a directory on the webserver 3. Login with credentials using localhost:3307 What is the expected output? What do you see instead? Expected output is to login to the database and see the list of databases/tables, i.e normal functionality. I get error message "There was a problem logging you in." and returned to the login dialogue. What version of the product are you using? On what operating system? SQLBuddy 1.3.1 Fedora Core 5, Fedora 7 and Ubuntu 8.10 PHP 5.1.2 MySQL 4.1.12 Please provide any additional information below. The php mysql_connect function takes the database host argument as server[:port] looking through the classes i see $connString uses : as delimiter for arguments so it will be stripping the port out. What steps will reproduce the problem? 1. Configure MySQL to use a non-standard port, i.e 3307 2. Install (unzip) sqlbuddy to a directory on the webserver 3. Login with credentials using localhost:3307 What is the expected output? What do you see instead? Expected output is to login to the database and see the list of databases/tables, i.e normal functionality. I get error message "There was a problem logging you in." and returned to the login dialogue. What version of the product are you using? On what operating system? SQLBuddy 1.3.1 Fedora Core 5, Fedora 7 and Ubuntu 8.10 PHP 5.1.2 MySQL 4.1.12 Please provide any additional information below. The php mysql_connect function takes the database host argument as server[:port] looking through the classes i see $connString uses : as delimiter for arguments so it will be stripping the port out. Mar 25, 2009 issue 18 (White page after login) commented on by alessandro.cinelli - same here. same here. Mar 25, 2009 issue 18 (White page after login) commented on by alessandro.cinelli - same here. same here. Mar 01, 2009 issue 19 (Timezone ID 'AMERICA/REGINA' is invalid) Status changed by calvinlough - Fixed now. Sorry for the wait. Status: Fixed Fixed now. Sorry for the wait. Status: Fixed Feb 18, 2009 r52 (Lots of small bugfixes. Also added five new translations.) committed by calvinlough - Lots of small bugfixes. Also added five new translations. Lots of small bugfixes. Also added five new translations. Feb 11, 2009 issue 22 (Auto Increment columns are not displayed or exported properl...) reported by barna...@bkendall.biz - To reproduce the problem, create a new table called "test" in any database and add the fields test_id (int) as an auto incrementing primary key and another field called test_data as a varchar. First of all, note that there is no indication that the column is auto incrementing on the table structure edit page. Next, export the test table as SQL. You will get output like this: CREATE TABLE `test` ( `test_id` int(11), `test_data` varchar(100), PRIMARY KEY (`test_id`) ) ENGINE=MyISAM DEFAULT CHARSET latin1; Notice that the auto increment data is missing. Export the exact same table through PHPMyAdmin and you get this: CREATE TABLE `test` ( `test_id` int(11) NOT NULL auto_increment, `test_data` varchar(100) default NULL, PRIMARY KEY (`test_id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ; The data is there, it just doesn't show up on the export. Results are unchanged if you drop the column and recreate it. It is always properly made, it just does not appear in the export. This was tested on the latest version of SQLBuddy as of this date (Feb 11, 2009). My computer is a Mac and SQLBuddy is running through MAMP. As a side note, it might be good to expose the version number on the home page for bug reports. Keep up the great work! To reproduce the problem, create a new table called "test" in any database and add the fields test_id (int) as an auto incrementing primary key and another field called test_data as a varchar. First of all, note that there is no indication that the column is auto incrementing on the table structure edit page. Next, export the test table as SQL. You will get output like this: CREATE TABLE `test` ( `test_id` int(11), `test_data` varchar(100), PRIMARY KEY (`test_id`) ) ENGINE=MyISAM DEFAULT CHARSET latin1; Notice that the auto increment data is missing. Export the exact same table through PHPMyAdmin and you get this: CREATE TABLE `test` ( `test_id` int(11) NOT NULL auto_increment, `test_data` varchar(100) default NULL, PRIMARY KEY (`test_id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ; The data is there, it just doesn't show up on the export. Results are unchanged if you drop the column and recreate it. It is always properly made, it just does not appear in the export. This was tested on the latest version of SQLBuddy as of this date (Feb 11, 2009). My computer is a Mac and SQLBuddy is running through MAMP. As a side note, it might be good to expose the version number on the home page for bug reports. Keep up the great work! Feb 09, 2009 issue 19 (Timezone ID 'AMERICA/REGINA' is invalid) commented on by san...@neofoto.nl - Same here I'm afraid.. Same here I'm afraid.. Feb 09, 2009 issue 18 (White page after login) commented on by mayank.r.jain - May be we should do some dependency checking and flag the missing modules upon login? May be we should do some dependency checking and flag the missing modules upon login? Feb 09, 2009 issue 18 (White page after login) commented on by mayank.r.jain - I get the same issue on GOS 3.0 (based on ubuntu)/ mysql 5.0 I get the same issue on GOS 3.0 (based on ubuntu)/ mysql 5.0 Jan 24, 2009 issue 19 (Timezone ID 'AMERICA/REGINA' is invalid) commented on by gpasci - same issue here. ubuntu 8.04. solved after editing the source file. same issue here. ubuntu 8.04. solved after editing the source file. Dec 19, 2008 issue 6 ('Save to file' option is buggy) commented on by stuart.loxton - Change line 195 of export.php from: if (isset($collationList) && $structureRow['Collation'] != "NULL" && !is_null($structureRow['Collation'])) { to: if (isset($collationList) && isset($structureRow['Collation']) && $structureRow['Collation'] != "NULL" && !is_null($structureRow['Collation'])) { SQL Exporting still works but there is no errors if there isn't a collation. EDIT: This is to fix the bug by hansdemu that the notice says there is no index: Collation Change line 195 of export.php from: if (isset($collationList) && $structureRow['Collation'] != "NULL" && !is_null($structureRow['Collation'])) { to: if (isset($collationList) && isset($structureRow['Collation']) && $structureRow['Collation'] != "NULL" && !is_null($structureRow['Collation'])) { SQL Exporting still works but there is no errors if there isn't a collation. EDIT: This is to fix the bug by hansdemu that the notice says there is no index: Collation Dec 19, 2008 issue 6 ('Save to file' option is buggy) commented on by stuart.loxton - Change line 195 of export.php from: if (isset($collationList) && $structureRow['Collation'] != "NULL" && !is_null($structureRow['Collation'])) { to: if (isset($collationList) && isset($structureRow['Collation']) && $structureRow['Collation'] != "NULL" && !is_null($structureRow['Collation'])) { SQL Exporting still works but there is no errors if there isn't a collation. Change line 195 of export.php from: if (isset($collationList) && $structureRow['Collation'] != "NULL" && !is_null($structureRow['Collation'])) { to: if (isset($collationList) && isset($structureRow['Collation']) && $structureRow['Collation'] != "NULL" && !is_null($structureRow['Collation'])) { SQL Exporting still works but there is no errors if there isn't a collation. Dec 12, 2008 issue 19 (Timezone ID 'AMERICA/REGINA' is invalid) commented on by bigdspbandj - I had the same issue. Same exact fix as bmhatfield as well. I had the same issue. Same exact fix as bmhatfield as well. Dec 12, 2008 issue 20 (When creating a new column of type ENUM, it isn't clear how ...) reported by bigdspbandj - When creating an ENUM column a values field pops up, but it is unclear as how to enter them. The values should either be formatted automatically or instructions on how to enter them should be visible. Currently they must be entered as: ('val1','val2') When creating an ENUM column a values field pops up, but it is unclear as how to enter them. The values should either be formatted automatically or instructions on how to enter them should be visible. Currently they must be entered as: ('val1','val2') Dec 11, 2008 issue 19 (Timezone ID 'AMERICA/REGINA' is invalid) commented on by bmhatfield - I also had this issue, but resolved it by changing my timezone to "America/New_York" (potentially case sensitive?). I had to edit the source files to make this change, which is probably a bit unintuitive. I also had this issue, but resolved it by changing my timezone to "America/New_York" (potentially case sensitive?). I had to edit the source files to make this change, which is probably a bit unintuitive. Dec 10, 2008 issue 6 ('Save to file' option is buggy) commented on by bmhatfield - I am also experiencing this issue - under Apache 2.2.3/CentOS and Apache 2.2/XAMPP-Windows. File download does not occur. I am also experiencing this issue - under Apache 2.2.3/CentOS and Apache 2.2/XAMPP-Windows. File download does not occur. Dec 02, 2008 issue 19 (Timezone ID 'AMERICA/REGINA' is invalid) reported by whiskybar - I'm getting the following notice on every page (just after installation, the version 1.3) Notice: date_default_timezone_set() [function.date-default-timezone-set]: Timezone ID 'AMERICA/REGINA' is invalid in /usr/local/share/sqlbuddy/functions.php on line 19 I believe it is kind of my fault because no one has complained about this. I'm using Ubuntu 8.10 (and 8.04). I also might be the thing I'm in Europe/Czech Republic and have not installed the required timezones or whatever. After reading http://us2.php.net/date_default_timezone_set I found I can use 'UTC'. SQL Buddy works flawlessly now. Do you think it would make sense to replace 'AMERICA/REGINA' with the more universal 'UTC'? I have attached a diff with the change if you believed it was a good idea and wanted to change it. Thank you for a great application! Jiri I'm getting the following notice on every page (just after installation, the version 1.3) Notice: date_default_timezone_set() [function.date-default-timezone-set]: Timezone ID 'AMERICA/REGINA' is invalid in /usr/local/share/sqlbuddy/functions.php on line 19 I believe it is kind of my fault because no one has complained about this. I'm using Ubuntu 8.10 (and 8.04). I also might be the thing I'm in Europe/Czech Republic and have not installed the required timezones or whatever. After reading http://us2.php.net/date_default_timezone_set I found I can use 'UTC'. SQL Buddy works flawlessly now. Do you think it would make sense to replace 'AMERICA/REGINA' with the more universal 'UTC'? I have attached a diff with the change if you believed it was a good idea and wanted to change it. Thank you for a great application! Jiri Nov 28, 2008 issue 18 (White page after login) reported by philippgerard - What steps will reproduce the problem? 1. Install Sqlbuddy on a server running Litespeed, PHP 5.2.6 (XCache) and mysqli 2. You see the login screen, enter your details 3. You'll see a blank page What is the expected output? What do you see instead? Sqlbuddy interface expected, white page as a result. What version of the product are you using? On what operating system? Linux Debian, Litespeed, PHP 5.2.6, XCache, mysqli & PDO-mysql available Please provide any additional information below. Is the mysql extension required or is mysqli just as good for Sqlbuddy? What steps will reproduce the problem? 1. Install Sqlbuddy on a server running Litespeed, PHP 5.2.6 (XCache) and mysqli 2. You see the login screen, enter your details 3. You'll see a blank page What is the expected output? What do you see instead? Sqlbuddy interface expected, white page as a result. What version of the product are you using? On what operating system? Linux Debian, Litespeed, PHP 5.2.6, XCache, mysqli & PDO-mysql available Please provide any additional information below. Is the mysql extension required or is mysqli just as good for Sqlbuddy? Nov 01, 2008 issue 17 (Set the width of tables dynamically) reported by goo...@phlogi.net - The width of the columns is set to a fixed value, which often wastes a lot of space. Could you adjust this size to a minmum according to the content of the columns? Thanks The width of the columns is set to a fixed value, which often wastes a lot of space. Could you adjust this size to a minmum according to the content of the columns? Thanks Oct 23, 2008 issue 16 (Sqlite version) commented on by gna...@se-media-solutions.de - Also strtolower in includes/browse.php on line 76 would be good =) if (strpos(strtolower($column[1]), "primary key") > 0) { Also strtolower in includes/browse.php on line 76 would be good =) if (strpos(strtolower($column[1]), "primary key") > 0) { Oct 23, 2008 issue 16 (Sqlite version) reported by gna...@se-media-solutions.de - I found another problem with sqlite. my sqlite extension is version 2.8.17 But in PDO i have sqlite 3 and sqlite 2 support. Now sqlite_libversion always returns 2.8.17 But my database is sqlite3 =) my sqlite connection code for sqlbuddy now: if ($this->adapter == "sqlite") { $this->method = "pdo"; if (class_exists('PDO') && in_array('sqlite2', PDO::getAvailableDrivers())) { // pdo_sqlite2 throw no exception on connect $this->conn = new PDO("sqlite2:" . $database, null, null, array(PDO::ATTR_PERSISTENT => true)); } if (is_null($this->conn) && class_exists('PDO') && in_array('sqlite', PDO::getAvailableDrivers())) { try { $this->conn = new PDO("sqlite:" . $database, null, null, array(PDO::ATTR_PERSISTENT => true)); } catch (PDOException $error) { $this->conn = false; $this->errorMessage = $error->getMessage(); } } elseif (is_null($this->conn)) { $this->method = "sqlite"; $this->conn = sqlite_open($database, 0666, $sqliteError); } } else { .... I found another problem with sqlite. my sqlite extension is version 2.8.17 But in PDO i have sqlite 3 and sqlite 2 support. Now sqlite_libversion always returns 2.8.17 But my database is sqlite3 =) my sqlite connection code for sqlbuddy now: if ($this->adapter == "sqlite") { $this->method = "pdo"; if (class_exists('PDO') && in_array('sqlite2', PDO::getAvailableDrivers())) { // pdo_sqlite2 throw no exception on connect $this->conn = new PDO("sqlite2:" . $database, null, null, array(PDO::ATTR_PERSISTENT => true)); } if (is_null($this->conn) && class_exists('PDO') && in_array('sqlite', PDO::getAvailableDrivers())) { try { $this->conn = new PDO("sqlite:" . $database, null, null, array(PDO::ATTR_PERSISTENT => true)); } catch (PDOException $error) { $this->conn = false; $this->errorMessage = $error->getMessage(); } } elseif (is_null($this->conn)) { $this->method = "sqlite"; $this->conn = sqlite_open($database, 0666, $sqliteError); } } else { .... Oct 23, 2008 issue 15 (Sqlite brings up JS error) commented on by gna...@se-media-solutions.de - found another thing with sqlite. My sqlite extension is sqlite 2. But in PDO it supports both sqlite3 and sqlite2. PDO::getAvailableDrivers() say: mysql, sqlite, sqlite2. so if you check "in_array("sqlite", PDO::getAvailableDrivers())", it should be enough Patch: --- Sql.php.orig 2008-10-23 16:26:30.000000000 +0000 +++ Sql.php 2008-10-23 16:57:05.000000000 +0000 @@ -40,7 +40,7 @@ $this->options = $opt; $database = (array_key_exists("database", $opt)) ? $opt['database'] : ""; - if ($this->adapter == "sqlite" && substr(sqlite_libversion(), 0, 1) == "3" && class_exists("PDO") && in_array("sqlite", PDO::getAvailableDrivers())) { + if ($this->adapter == "sqlite" && class_exists("PDO") && in_array("sqlite", PDO::getAvailableDrivers())) { $this->method = "pdo"; try @@ -463,7 +463,7 @@ $output .= '{"name": "' . $this->db . '"'; $tableSql = $this->listTables(); - if ($tableSql) { + if ($tableSql->rowCount() > 0) { $output .= ',"items": ['; while ($tableRow = $this->fetchArray($tableSql)) { $countSql = $this->query("SELECT COUNT() AS 'RowCount' FROM '" . $tableRow[0] . "'"); found another thing with sqlite. My sqlite extension is sqlite 2. But in PDO it supports both sqlite3 and sqlite2. PDO::getAvailableDrivers() say: mysql, sqlite, sqlite2. so if you check "in_array("sqlite", PDO::getAvailableDrivers())", it should be enough Patch: --- Sql.php.orig 2008-10-23 16:26:30.000000000 +0000 +++ Sql.php 2008-10-23 16:57:05.000000000 +0000 @@ -40,7 +40,7 @@ $this->options = $opt; $database = (array_key_exists("database", $opt)) ? $opt['database'] : ""; - if ($this->adapter == "sqlite" && substr(sqlite_libversion(), 0, 1) == "3" && class_exists("PDO") && in_array("sqlite", PDO::getAvailableDrivers())) { + if ($this->adapter == "sqlite" && class_exists("PDO") && in_array("sqlite", PDO::getAvailableDrivers())) { $this->method = "pdo"; try @@ -463,7 +463,7 @@ $output .= '{"name": "' . $this->db . '"'; $tableSql = $this->listTables(); - if ($tableSql) { + if ($tableSql->rowCount() > 0) { $output .= ',"items": ['; while ($tableRow = $this->fetchArray($tableSql)) { $countSql = $this->query("SELECT COUNT() AS 'RowCount' FROM '" . $tableRow[0] . "'"); Oct 23, 2008 issue 15 (Sqlite brings up JS error) commented on by gna...@se-media-solutions.de - Only happens if you dont have any tables in your sqlite db Only happens if you dont have any tables in your sqlite db Oct 23, 2008 issue 15 (Sqlite brings up JS error) reported by gna...@se-media-solutions.de - Choose Sqlite type in your db (here: test.db) then Submit JS errors appear: syntax error var menujson = {"menu": [{"name": "test.db","items": ]}]}; //-->\n Line 69 here is a patch: --- Sql.php.orig 2008-10-23 16:26:30.000000000 +0000 +++ Sql.php 2008-10-23 16:26:43.000000000 +0000 @@ -463,7 +463,7 @@ $output .= '{"name": "' . $this->db . '"'; $tableSql = $this->listTables(); - if ($tableSql) { + if ($tableSql->rowCount() > 0) { $output .= ',"items": ['; while ($tableRow = $this->fetchArray($tableSql)) { $countSql = $this->query("SELECT COUNT() AS 'RowCount' FROM '" . $tableRow[0] . "'"); Choose Sqlite type in your db (here: test.db) then Submit JS errors appear: syntax error var menujson = {"menu": [{"name": "test.db","items": ]}]}; //-->\n Line 69 here is a patch: --- Sql.php.orig 2008-10-23 16:26:30.000000000 +0000 +++ Sql.php 2008-10-23 16:26:43.000000000 +0000 @@ -463,7 +463,7 @@ $output .= '{"name": "' . $this->db . '"'; $tableSql = $this->listTables(); - if ($tableSql) { + if ($tableSql->rowCount() > 0) { $output .= ',"items": ['; while ($tableRow = $this->fetchArray($tableSql)) { $countSql = $this->query("SELECT COUNT() AS 'RowCount' FROM '" . $tableRow[0] . "'"); Sep 29, 2008 r51 (Fixed problem when creating a large number of users.) committed by calvinlough - Fixed problem when creating a large number of users. Fixed problem when creating a large number of users. Sep 28, 2008 issue 6 ('Save to file' option is buggy) commented on by hansdemu - Indeed, I also got that error. I also get a bunch of errors exporting... (both browser & file): Notice: Undefined index: Collation in /home/user/**/www..be/sqlbuddy/ export.php on line 195 Indeed, I also got that error. I also get a bunch of errors exporting... (both browser & file): Notice: Undefined index: Collation in /home/user//www.**.be/sqlbuddy/ export.php on line 195 Sep 26, 2008 issue 14 (Bug in encoding) Status changed by calvinlough - This problem was fixed in the 1.3.0 release. I performed the steps that you described and came out with the output from step 6: 54 C3 A9 C3 A8 73 74 Calvin Status: Fixed This problem was fixed in the 1.3.0 release. I performed the steps that you described and came out with the output from step 6: 54 C3 A9 C3 A8 73 74 Calvin Status: Fixed Sep 19, 2008 issue 14 (Bug in encoding) reported by e.akerboom - SQL buddy (1.2.9) seems to be having troubles with character encoding. Text issued by the user is encoded twice before it is stored in the database. I've attached a screenshot of this issue to make sure the information is presented correctly. Steps to reproduce: 1. Run the following SQL: DROP TABLE IF EXIST test; CREATE TABLE TEST (id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(255) CHARACTER SET utf8) DEFAULT CHARACTER SET utf8; 2. Go to table test, and insert a new row with the name "Téèst" 3. Go to the 'browse' view, and check that a row with id '1', and name 'Téèst' is indeed present 4. Now run the following SQL: SELECT HEX(name) FROM test WHERE id=1 5. The result of this query is 54 C3 83 C2 A9 C3 83 C2 A8 73 74 which, if translated to ASCII, is the string 'TÃƒÂ©ÃƒÂ¨st' 6. The result of this query should have been 54 C3 A9 C3 A8 73 74 which, if translated to ASCII, is the string 'TÃ©Ã¨st' If you encode that string to UTF8, then you obtain the string from point 5. 7. In other words, SQL Buddy converts input to UTF-8 TWICE. Any user input is converted to UTF-8, which is then converted to UTF-8, which is eventually stored in the database. SQL buddy (1.2.9) seems to be having troubles with character encoding. Text issued by the user is encoded twice before it is stored in the database. I've attached a screenshot of this issue to make sure the information is presented correctly. Steps to reproduce: 1. Run the following SQL: DROP TABLE IF EXIST test; CREATE TABLE TEST (id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(255) CHARACTER SET utf8) DEFAULT CHARACTER SET utf8; 2. Go to table test, and insert a new row with the name "Téèst" 3. Go to the 'browse' view, and check that a row with id '1', and name 'Téèst' is indeed present 4. Now run the following SQL: SELECT HEX(name) FROM test WHERE id=1 5. The result of this query is 54 C3 83 C2 A9 C3 83 C2 A8 73 74 which, if translated to ASCII, is the string 'TÃƒÂ©ÃƒÂ¨st' 6. The result of this query should have been 54 C3 A9 C3 A8 73 74 which, if translated to ASCII, is the string 'TÃ©Ã¨st' If you encode that string to UTF8, then you obtain the string from point 5. 7. In other words, SQL Buddy converts input to UTF-8 TWICE. Any user input is converted to UTF-8, which is then converted to UTF-8, which is eventually stored in the database.

issue 27 (Cannot manage users on a remote database server) reported by brian.cline - What steps will reproduce the problem? 1. Install Apache and MySQL on separate boxes, and SQL Buddy on the Apache box. 2. Create a user in MySQL with full privileges with a host or IP of the Apache box. 3. Log in with SQL Buddy and navigate to the Users screen. What is the expected output? What do you see instead? Expected output is the full user management console. Instead, I see a list of existing users but the bottom panel says "You do not have enough permissions to create new users." What version of the product are you using? On what operating system? The latest version from the web site (cannot find any screens in SQL Buddy that mention the current version number - this probably ought to be added to the home screen somewhere). Running on CentOS 5.3, PHP 5.3.0, MySQL 5.1.39. Please provide any additional information below. It appears that SQL Buddy is querying the mysql.users table by logged-in user name and database server name to check permissions, rather than using the user name and local server name for which a grant was created. So, for example, my web server ads-web-01 runs SQL Buddy to connect to ads-db-01. SQL Buddy is looking in the users table for a record for sqlbuddy@ads-db-01, when it should be looking for sqlbuddy@ads-web-01. I've been able to work around this bug by modifying the query at users.php:440 to read thusly: $checkSql = $conn->query("SELECT `Grant_priv` FROM `user` WHERE `Host`=(SELECT SUBSTRING_INDEX(USER(), '@', -1)) AND `User`=(SELECT SUBSTRING_INDEX(USER(), '@', 1)) LIMIT 1"); This takes advantage of the built-in MySQL function USER(), which returns the current user name and originating hostname in a single-column result (i.e., 'sqlbuddy@ads-web-01.domain.com'). After applying this fix, user management still appears to work fine when connecting to a local MySQL instance, as USER() returns 'sqlbuddy@localhost'. So if you were to make the same fix to the repo, then the majority of your users ought not notice any difference as I imagine most of them run MySQL and SQL Buddy on the same machine.

What steps will reproduce the problem? 1. Install Apache and MySQL on separate boxes, and SQL Buddy on the Apache box. 2. Create a user in MySQL with full privileges with a host or IP of the Apache box. 3. Log in with SQL Buddy and navigate to the Users screen. What is the expected output? What do you see instead? Expected output is the full user management console. Instead, I see a list of existing users but the bottom panel says "You do not have enough permissions to create new users." What version of the product are you using? On what operating system? The latest version from the web site (cannot find any screens in SQL Buddy that mention the current version number - this probably ought to be added to the home screen somewhere). Running on CentOS 5.3, PHP 5.3.0, MySQL 5.1.39. Please provide any additional information below. It appears that SQL Buddy is querying the mysql.users table by logged-in user name and database server name to check permissions, rather than using the user name and local server name for which a grant was created. So, for example, my web server ads-web-01 runs SQL Buddy to connect to ads-db-01. SQL Buddy is looking in the users table for a record for sqlbuddy@ads-db-01, when it should be looking for sqlbuddy@ads-web-01. I've been able to work around this bug by modifying the query at users.php:440 to read thusly: $checkSql = $conn->query("SELECT `Grant_priv` FROM `user` WHERE `Host`=(SELECT SUBSTRING_INDEX(USER(), '@', -1)) AND `User`=(SELECT SUBSTRING_INDEX(USER(), '@', 1)) LIMIT 1"); This takes advantage of the built-in MySQL function USER(), which returns the current user name and originating hostname in a single-column result (i.e., 'sqlbuddy@ads-web-01.domain.com'). After applying this fix, user management still appears to work fine when connecting to a local MySQL instance, as USER() returns 'sqlbuddy@localhost'. So if you were to make the same fix to the repo, then the majority of your users ought not notice any difference as I imagine most of them run MySQL and SQL Buddy on the same machine.

Older