I have a database that I create through phpMyAdmin. Then I update it by creating tables in it via a script. All fine til now, then I use it. Two days later I drop this database altogether. Then I create another one with a different name, create something in it as well. Drop it too. Then I create a database with the same name as the first one, again creating tables in it. I leave it that way to find out that the next day I login I get the first database (with its contents) rather than the thing that I expected.
This type of weird behaviour happens no matter how you turn it. The same name is not the problem I think since I know it can happen with databases that carry different names. (I've tried it)
Basically it's like this thing forgets about it's state. What is happening? Any ideas?
This thing is driving me nuts since I can't do anything without fearing that I lose data.
I'm using windows with Zend Server.
I am NOT accidentally dropping tables or something like that.
EDIT: It seems that an immediate restart does not have any effect (meaning it keeps things as is, the random changes happen only after a certain period of time (more than a day)
Databases are stored on disk as folders containing:
one file describing the structure of each table
another file containing all of the tables' rows
one file for each index/key you define
some files (just allocated blocks) intended to allow storing large data such as text-columns or blob-columns which do not reside in the tables' rows (the rows only have a reference to where the blob resides).
When dropping a table the OS deletes some files. When dropping a database the OS deletes a folder.
It is possible (though very unlikely) that the database folder wasn't correctly deleted in the first place -- be it a permission issue on how you installed your server or a server bug or a phpMyAdmin bug.
Related
I am unsure about the best way to do this. As I'm getting ready to put a new database into production, I need to import data from the old database that has been formed in the meantime of me working on it. The new database now also contains a lot of fake data that was used for testing, which I have to get rid of, so a fresh complete re-import seems reasonable.
Now, truncating all the tables in the new database cannot go through, because the foreign keys prevent it. Simply deleting the data instead would solve that problem, but it leaves the AUTO_INCREMENT indexes to the values where they were, so it's not a "proper" wipe. Now, there could be more properties such as that one, that would be left over (so to say), but this is the only one that I'm aware of.
So my question now is, how much of a problem could these "leftover" pieces of data pose to performance, if I were to go with the simple DELETE solution?
And also; is there a way that would be more thorough in cleaning it out, and also allow me to, of course, keep the defined constraints?
First i would use some gui tool to create the dump for the old DB ( like mySql workbench, or what ever you prefer ). Check options "Export to self-contained file", and check "Dump stored procedures and functions","Dump events" and "Dump triggers".
Then get create scripts for all tables not included in the old DB.
You can do this via "reverse engineer" option.
If you have trouble with this part this post will help.
How to get a table creation script in MySQL Workbench?
When you have old DB dump and create scripts for new sql tables, combine them to a single sql file.
On the first row add:
SET FOREIGN_KEY_CHECKS = 0;
On the last row add:
SET FOREIGN_KEY_CHECKS = 1;
Run the script. As a result you should have all tables ( new without data and old with data ), with all relations set properly. Hope it will work for you.
I updated the SCHEMA of a live table in MySQL for use in my multi-user database. Each user has their own db and links to the production tables through ODBC.
I have been receiving a write error while trying to test my schema updates. I cannot find the core reason. I hypothesized that because the other users are in the production table but have not been relinked to update the table SCHEMA; That it is causing a conflicting write error on my relinked table.
I added a TINYINT with No NULLS and default value of 0
I double checked all datatypes for incompatibility & have tested the "non relinked" tables in a older version of the DB and confirmed it is working as intended with no errors
I expect/want to be able to edit records without a write error, but am hesitant to update the other users to the new table if it is currently having write errors
After changing the schema of a linked table, it's required to refresh the link on all Access databases connected to it.
You can do this on the ribbon through external data -> linked table manager.
Unfortunately, either all users that have a database need to do this manually, unless you automate the task on startup through vba.
You have two separate issues. To "see" new columns, then yes, you must re-link the tables.
(so above is separate question and separate issue). You thus as a general rule can add new columns to the database (even while in use). However, the client side linked tables will not see the new columns until such time you re-link. This approach (adding new columns, but not yet re-linked from Access) is certainly ok and fine - the only downside is end users can't see nor use the new columns until such time you link. From a developer point of view, this good - since your users will not see nor find new columns until such time you roll out a new front end to each work station.
Ok, now problem and issue number two.
As for adding a new column, then re-linking, and THEN having some issue is really a separate issue. In most cases, if you attempting to use a tiny int as a Boolean (and I think that is your case), then you need to ensure several things:
Do not allow nulls (you seem to have this ok).
Make sure you set a default of 0 (server side) for this column. (you might have not allowed nulls, but without a default, then Access likely will still complain. And this default is important during creating time - since the new column needs to be "filled" with zeros.
Make sure the table has a PK defined.
Consider adding a row version column (I think mySQL has these, not sure but they can help immensely).
I'm wondering if there is any better way than going through the tables one by one adding the columns missing when some fields/tables needs to be added because of the most recent changes in the app?
For example, I'm working at the localhost and when I finish doing the new version of my app, I will put all the files into my FTP and, sometimes, I have done, in my local database, changes and so it means that I also need to update my database at my server.
There's any better way to add/edit the columns/tables without changing the info? Some of the columns are also deleted, etc.
Hopefully you've thought your database design through so that making changes to the structure is a rare occurrence. If you're making regular changes to the number of columns or adding tables, it's likely a sign that you haven't normalized your database structure sufficiently.
Anyway, I'd script it as an SQL file that you deploy (which you can then run through phpMyAdmin or the command line or any other means you prefer to execute SQL queries). This has the added advantage of being something you can easily duplicate across your development and production databases, send to customers, and if you wish store in version control so you know when exactly you made the changes to the database.
This way, you'll end up with an SQL file that has a couple of statements like
ALTER TABLE `foo` ADD `new` INT NOT NULL ;
or something similar.
As for how you'd make the file, probably the easiest way is just copying and pasting the generated SQL statement from phpMyAdmin after modifying the table -- the SQL code used to make the change is shown near the top of the screen on the next page. You can copy and paste that to a new text file to create your SQL file. You may wish to add the first line
use `baz`;
using your database name instead of "baz". That way you don't have to specify on import which database the changes are meant for.
Hope this helps.
Early on in my design phase I made the mistake of renaming a table and then creating a new table with the old name. For some reason, MySQL Workbench decided to remember this fact very well. Now every time I try to synchronize with a database, MySQL Workbench wants to rename the (new) table back to its old name.
I did this:
Rename my_table => my_new_table
Create new table called 'my_table'
And now MySQL Workbench insists this would be the right way to proceed:
Rename my_new_table => my_table
Drop my_new_table
That's clearly a bug in its own right, but how is MySQL Workbench keeping track of what it has done with the tables of a random DB? Is there some metadata somewhere I can clear to make MySQL Workbench to believe that this change has already taken place and need not to be repeated? Clearly Workbench is doing more than just a diff between the model and the existing database...
(I realize I could just ignore the the particular step in synchronization process, but I don't want to do it every time I synchronize and of course any changes to these two particular tables would be never carried out...)
Managed to work around the issue by running synchronization once with "skip DB changes and update model only". Unclear whether there are bits of the schemata out of sync or not, but at least new changes now carry over.
Renaming an object and creating a new one with the same name is a special case which makes it quite difficult for the synchronization process. The reason is that Workbench uses the names to find objects (as there is no other identification mechanism like UUIDs or similar). So extra steps are done to find such a rename situation. Workbench explicitly keeps the old name to have a way to find what to sync how.
I have a procedure mst2 which creates a minimum spanning tree and updates a table MST in my database with several values. It works fine with WAMP but acts crazy when I try to import it on a live server.
Currently, every time I reload the table random values appear in it and seem to go up and down?? I have no idea what's going on. I'm not even calling the function but the table appears to be dynamically adjusting constantly.
I would post my code but it might be overkill, it's pretty extensive. If anybody has a general idea about what can cause this please let me know.
The problem was the fact that I was referencing the table in lowercase as 'mst' in some parts of the code relying on the fact that MySQL isn't case sensitive. Apparently the server I was importing to (Linux) had MySQL configured to be case sensitive for table (and possibly column?) names, fixing the table name in the code from lower to upper solved the issue.