I'm trying to change the SQL query under the SQL tab in PhpMyAdmin but the old code keeps coming back every time I navigate off that page (and thus, giving me an error message again). How can I stop it from reverting back to it's old erroneous code? I have the new code at the ready. Is there some sort of setting I need to tweak?
Actually, I don't really need any code here at all, unless it's required. I'm new to PhpMyAdmin and just want to set it up so that I can follow along with a video tutorial.
When I try to click on the Databases tab
The old code in the SQL tab. Keeps coming back...
Note: The code was changed to that shown below that works. But it "reverts" back somehow. Good code:
It appears to be a version incompatibility. Your screenshot shows you using MySQL version 5.7 with phpMyAdmin 4.2; this is not supported and guaranteed to not work properly. For use with MySQL 5.7, you should use the latest phpMyAdmin (which is currently the 4.6 branch; 4.6.4 was released on 2016-08-16).
For more information about version compatibility, see the "Requirements" section of the documentation included with each download, or the information listed with each version at https://www.phpmyadmin.net/downloads/
Related
Bit of a back story, I was using MySQL Server 5.X on an old server. Retired server and migrated all data to a new server with MySQL 8.0.11 (now 8.0.12) installed. Used Legacy authentication to reduce issues.
This seemed to work and all my programs open/ran as expected. I've been editing them and publishing without any issues as well, however in that time I have not had any reason to change any of the data sources.
I've gone to change the data source today though and can not get it to work for the life of me.
If I try and make any changes I get the error "Configure TableAdapter tbl_users failed. Specified cast is not valid.". Obviously the table name varies and this happens regardless of which table (even trying to add a new table that I've just created).
It seems to work though, but on closer inspection, the delete and update commands are not created which means if I try and run the application I just get errors.
I've currently got:
Visual Studio 2015
MySQL Connector Net 6.9.8
MySQL for Visual Studio 1.2.7
Thanks in advance for any help/ideas.
#A Tyler. I suggest trying to update the MySQL for Visual Studio and MySQL connector to the newest versions. Have you tried that?
I think this issue is somehow related with the one described here.
https://bugs.mysql.com/bug.php?id=31338
This bug dates back to version 5.1 of the connector and VS 2005... should have been fixed right now, but the symptoms are very similar.
Maybe you found any other solution?
Update:
I 'slept' with the problem and found a workaround on the next day. This does not really solve the issue but made it possible to continue with the project.
I went to the 'properties' window of a table adapter and manually edited select and update commands there. It caused the table adapter to reflect these changes and I could use the new table field in my program. For me, this is good enough.
I have multiple versions available in Version Control of my Spreadsheets Script editor. The most recent one is after a complete rewrite of the server side commands and malfunctions terribly at the moment. I have reverted to the last known good version and things are working well at the moment, but something small has come up that requires changing. Here is the issue - i no longer seem to have access to the source of the old version. I can choose to make the old version live, so i figure the source might still be stashed somewhere. Can it be accessed?
When running mysql-workbench on Ubuntu 14.10 I am getting unexpected behavior in the GUI. If I double click on a table in the EER diagram editor I can't see a list of columns and their attributes. My screen looks like this:
When I double click on a table in the diagram editor the expected behaviour is to list each column in the table along with its attributes within the area highlighted in pink. I should be able to modify, delete, and add columns.
Why am I seeing this behaviour and how can I fix it?
I can confirm the behavior you are seeing. It doesn't work on Ubuntu 14.10 and works On Ubuntu 14.04. I use mysql-workbench on Debian Wheezy with the expected behavior. So your question caught my attention because it appeared to be a bug.
I ran it from the command line to see what was on the console. When using the EER Diagram Editor with a sample model I was greeted with a blank pane where columns and their attributes should be listed. The console shows these unexpected assertions:
(mysql-workbench-bin:52041): GLib-GObject-WARNING **: attempting to add an interface (GtkTreeDragDest) to class (gtkmm__CustomObject_16ListModelWrapper) after class_init
(mysql-workbench-bin:52041): GLib-GObject-WARNING **: attempting to add an interface (GtkTreeDragSource) to class (gtkmm__CustomObject_16ListModelWrapper) after class_init
(mysql-workbench-bin:52041): Gtk-CRITICAL **: IA__gtk_tree_view_set_model: assertion 'model == NULL || GTK_IS_TREE_MODEL (model)' failed
There were far more errors but I have cut the list short. These assertions suggest to me that there is a bug while creating the window pane where the column data. It isn't just the column data where this happens but on a majority of the panes at the bottom.
I work on an open source project that also had issues with Ubuntu 14.10 and it also involved Glib assertions appearing where they didn't occur before. The Glib developers have begun adding more assertions to their code to identify software bugs. It is possible that something similar applies here. In the case of the project I maintain the assertions were indicative of a problem in our project code and the newer versions of Glib made our code fail.
With that in mind I looked on the Ubuntu launchpad site. There is this bug report with the title Workbench not showing tables or query results in raring that was opened last year but people are now identifying the issue with 14.10 as well (many in the past week). I believe it is related to what you are seeing. I also observed there are nearly 3 dozen people at this time that have reported a problem. You could create an account and add yourself to the list of people experiencing a problem.
There is good news and bad news. The MySQL workbench developers have identified and fixed the problem in their latest builds. The MySQL bug report link has this to say:
Posted by developer:
Fixed as of the upcoming MySQL Workbench 6.2.4 release, and here's the changelog entry:
On Linux, the query result view did not populate with libglib version 2.42
and above.
Unfortunately Ubuntu doesn't have a patch or work around in their official repositories yet. I think you have a few options:
Don't use mysql-workbench on Ubuntu 14.10 until the bug is fixed and a new version of mysql-workbench is released by Ubuntu.
Use an older version of Ubuntu (like 14.04) where it does work because it uses an older version of GLib
Download the source and build your own version of MySQL Workbench 6.2.4 or later when the source is released. At the time of this writing the source hasn't officially been released.
Download and build from the source for MySQL Workbench 6.2.3 using this patch . This patch was provided in the MySQL bug report linked to above.
There isn't much to tell just from your image. So I'll provide you will some common fixes for this problem:
Close and Restart MySQL Workbench
Right-click on your schema (or table) and click "refresh"
Right-click on the column window (red part) and click "refresh"
Sometimes this happens, not all programs are perfect (you loaded a good amount of data).
I been using mysql 5.6 for a while now,
Sometimes when I make some changes in the procedure , table or function and try to save them MySQL refuses to save them and shows a error message like "No Changes detected". here I am not talking about changing cases or managing spacing. Even If I add some new column and add new condition in the procedure its unable to detect the change
Can anybody help me out with this MySQL bug
I have even upgraded to MySQL 5.7 but still problem persist.
I overcome this bug by removing the "DEFINER=root#localhost" part from the editor and then click on "Apply". It works 99% of times.
Eg: For a function or procedure, below is the declaration you see at top. Just remove the DEFINER string as described above and try it.
CREATE DEFINER=root#localhost FUNCTION/PROCEDURE
Since this is not a MySQL server error response, I assume you are trying to update your procedures with the MySQL visual tool workbench (http://www.mysql.com/products/workbench/)
I found bug reports on mysql.com pointing out similar issues. http://bugs.mysql.com/bug.php?id=68434
Those might be fixed with the latest version 6.0 of MySQL workbench.
If not, a possible workaround would be to drop and recreate procedures.
If you are using MySQL Work bench this means that the SQL script is identical to the copy in the database.
This generally happens for 1 of 2 reasons
Either the Files are Identical, or the script failed to parse as valid SQL and its has then defaulted to the original script. if you check the message log then the second one should say
Action:Apply changes to [scriptName]_SYNTAX_ERROR
Message:No changes detected
this can be confusing as the Commit Dialogue only displays the message not the action
I recently upgraded from Mysql workbench 5.x to 6.0.7.11215, And I am noticing strange slowness problem.
Whenever I try to edit the query, move the cursor around, or just try to add any characters, the editor hangs for a bit for a few seconds, and then resume normally.
This only happens when I am using a slow network connection to the server.
This issue was never there in the old Mysql workbench verison 5.x.
I disabled autocomplete, and restarted the program, but the issue is still there.
I used wireshark to examine the network traffic, and noticed a few of SSH packets at the time of the slowness, but I can't really know what is in them since, since the packets are encrypted. (it is worth noting that I am using database connection over an ssh tunnel)
I guess the slowness happens because of the context help. This feature queries the server's help tables to get help information for a specific topic that MySQL Workbench derives from the current caret position. Try this: hide the context help pane (activate snippet tab or hide the right side bar). If that context help pane is not visible no help queries are sent.
For more information about the context help see my blog post here: http://mysqlworkbench.org/2013/08/mysql-workbench-6-0-help-is-on-the-way/
work around: in the query place some extra comma by which the current line becomes x- in red colour
do all the editing ;
it won't go hang state
finally remove comma and execute
Set limit rows in query results to 1000 go in: Edit -> Preferences -> SQL Queries and check the limit to 1000
Workbench 6.1