i am using cakephp 1.3 ...it was working like charm in server ,i copied it to local and executed it....after that it shows a wierd error .It says "Missing Database Table
Error: Database table inboxes for model Inbox was not found.
Notice: If you want to customize this error message, create app/views/errors/missing_table.ctp
"
things i did after copying to local:
i used same DB with different name (yes..i changed in database.php too)
But there exist table "inbox"
I tried these ways:
1.removed inbox model and controller--nothing hapened
2.removed cache file from app/tmp/cache/models ---nothing happened
3.disabled caching from core.php
when i used another table with same name as in server its working
But nothing seems to be working after i used another database name as i am using that db name for another app ....can anyone help me on this...whats really happening with this.,its urgent..thanks in advance...
As Joseph mentioned in the comment, it may be a spelling mistake. But there could be one more reason:
On the web servers sometimes (mostly on shared hosting) you have the database name prefix. So it is possible that the real name of the database on your server is different from the database on your localhost. You can configure this in your app folder config/database.php
Best regards,
Tony.
After days of headache i sorted it out.
Even if i was using same DB with different name,it was using different encoding .I created new db with uttf_genereal_ci encoding and imported old one into it.Now its working like charm.Thanks guys for helping me on this
Related
I'm trying to migrate a WordPress site to some new hosting. The site is an older site, created probably 7+ years ago. I'm getting an error from wordpress upon bringing it to the new server that gave me a heads-up that the WP tables have no prefix. Sure enough, I login to Phpmyadmin, and there are no prefixes on the tables. I have since tried several methods to add prefixes and get the site migrated, but all are coming up short:
Direct DB dump from phpmyadmin on old server, import into new server. Triggers "tables have no prefix" error
Use updraft plus to get the backup from old server, restore to new server (triggers "tables have no prefix" fatal error)
Revised #1(above) approach - db dump/import/restore, manually add (via operations tab in each table) wp_ prefix to all tables. Site loads, but logging in as admin then yields no access to wp-admin dashboard (black bar at top after login, but no options for doing anything on the dashboard). I have tried the various tricks suggested, like adding a new temp admin user or trying to make necessary changes in usermeta table to my admin user, but that doesn't resolve it.
Tried using the All In One WP Security plugin to add new prefix. It recognizes the current no prefix, but won't successfully complete adding the prefixes to the DB. Tried another plugin and didn't even get that far.
Using Phpmyadmin, I've tried to use the built-in add prefix, and that seems to not work either.
I just looked at phpmyadmin again after trying unsuccessfully to use the built-in add prefix function, and am noticing that while all tables are InnoDB, the collation is a mix of utf8_general_ci and utf8mb4_unicode_ci . I understand that the second option is probably what I want all of them to be. I was able to add prefixes to the tables that are utf8mb4_unicode_ci, but the rest of them simply do not respond to that function in phpmyadmin.
The next thing I tried was to change all the collation to utf8mb4_unicode_ci using phpmyadmin. I used the "change all tables collations" and "change all tables columns collations". That seemed to work and then allowed me to add a prefix. However, after that, while the site was still working, I could again no longer get into the wp-admin dashboard. If I were to try the same conversion but only doing the "change all tables collations" and skipping the second option, I wonder if that might work. Just tried converting the tables without converting all the columns. The site seems to still work ok after doing that. But trying again to add prefix using the AIO WP security plugin still doesn't complete.
It would seem that adding the prefix is causing the issue. Is this something that a theme could be interfering with for some reason? What am I missing here?
Any tips for moving forward with this site? Thanks so much.
You can simply dump the database, open it with a text editor, replace all occurrences of "CREATE TABLE " with "CREATE TABLE yourprefix_" and restore the database.
It should be easy, depending on the size of the dump.
I tried adding a new table into one of my models in Web2Py. In addition I added a new field to an existing table. I tried loading a page that used those tables and it didn't work, claimed those things don't exist. Okay so I get migrations to False here.
db = DAL('sqlite://storage.sqlite',pool_size=1,check_reserved=['all'], migrate = False)
Reloaded the page, no change. Then I tried doing something like this in the tables it wouldn't understand
db.define_table(....,migrate=False,fake_migrate=True)
and I changed the DAL call to be
db = DAL(...,fake_migrate_all=True)
As the web2py manual said. Still no change. So then I said well okay I will have to dumb the whole database. So I took everything out of my database folder and I tried to reload it with a clean slate.
Now it just doesn't load at all.
According to database administration none of the tables exist although if I check again in the database folder they are all there. If I try to load the application it immediately reports that none of my called tables exist. I have all the code backed up on a repo but I can't uninstall the current app because I don't have that kind of read access on the server this is running on.
Is there anything I can do?
Edit: By the way this is happening on SQLite
Have you already tried, besides dumbs DB, clean up the database folder? If you do not do this, web2py will goes insane, cuz the files says that there are tables, but db don't. Besides, take a look in here, about fixing broken migrations and some caveats about sqllite.
intellij idea data sources doesn't see existing table in my mysql database, while Netbeans see it.
i've created a table in the database. When i create connection in intellij idea data sources, it sees my scheme, i do select it in "schemas and tables" but then i don't see it in the list.
every schema, but mine's. When i try to connect to it with netbeans or mysql workbench, it's just ok. same story with several databases, with root access, too. any table, but mine's.
what could be wrong?
i see question like mine's here, related to visual studio, no answer.
please, give a good clue
I had the same problem in IntelliJ IDEA 15.
I fixed it by right clicking the data source -> Properties -> Schemas -> Use legacy introspector.
I found the reason of problem for HSQLDB: There is IDEA bug (i have 11.0 version).
Create db with relative path (relative of MODULE), like this:
jdbc:hsqldb:file:db_file/testDBInMemory;shutdown=true;hsqldb.write_delay=false;
f:\TestModule\db_file\
When added it to Data Sources, IDEA recognizes this path as relative of $IDEA_HOME$/bin folder.
f:\Program Files\JetBrains\IntelliJ IDEA 11.0\bin\db_file\
So you have two different data bases. And when JPA updated first, Data Source doesn't see update in other.
WORKAROUND:
use absolute path in file db url.
For the latecomers still experiencing this, Intellij IDEA also has the following features which might help you as they have me:
'Force Refresh' (ctrl + shift + F5): "The Force Refresh action clears the data source information from cache and loads it again from scratch."
'Forget Cached Schema' which clears the schema cache. Does require you to set which schema you want shown again.
Right click your datasource -> Diagnostics -> 'Force Refresh' or 'Forget Cached Schema'
Source: https://www.jetbrains.com/help/idea/cannot-find-a-database-object-in-the-database-tree-view.html
The answer for me was buried in a comment, so I'm posting it here. The symptom for me was seeing an error like this:
Unable to resolve table 'thetablename'
And the table name was highlighted in red.
The following fixes are all ways to trigger IntelliJ to refresh data sources:
CTRL+ALT+Y to refresh the db stuff, or
CTRL+F5, or
Click the database vertical tab on the right, expand, right-click on each DB connection and select 'Refresh'
Kudos to #ice for answering this earlier in a comment. I'm basically just elaborating and making sure this shows up as an answer.
I'm having some trouble with a django database (postgresql backend).There was a model (a profile for users) in the project with some boilerplate stuff in it. This has sat in our project for a while, not being used. I actually got round to needing this, so I adjusted the models and created some initial migrations with South. On my dev box I dropped the entire db and syncdb'ed and migrated. This worked fine.
When I've pushed this out to production, I manually removed the old tables in postgresql and syncdb'ed and migrated. However, in my admin interface a DatabaseError is raised as some function is looking for a field on the old model. I've even dropped the entire postgresql database and syncdb'ed / migrated again and this still happens. The offendinging field is called gender (not one that I created). The migration works, and the database structure reflects my models, but for some reason the admin interface wants to find this (non-existant) gender field. This is the error:
DatabaseError: column user_profiles.gender does not exist LINE 1: ... "user_profiles"."id", "user_profiles"."user_id", "user_prof...
I understand this seems to be quite site specific, but perhaps I could get some pointers on how to debug this?
Thanks
If I understand your problem, your current code should not contain a reference to "gender" any more, since the old code was removed. Try to find a source file which still contains it:
find your-dir -name '*.py'|xargs grep gender
Or there is a pyc file, but the py file was removed. But Python still loads the pyc file....
If this does not help, please post the ascii traceback.
I've looked around the Wordpress forums about this and didn't find anything so I thought I might try here.
If you have a staging/dev Wordpress setup used for testing new pluging and such, how do you go about migrating the data in the staging database back to the production database? Is there a "Wordpress best practices" way to do this, or am I limited to having to manually migrate tables from one database to the other?
I have a script that mysqldumps a copy of my production Wordpress DB, restores it over my test Wordpress install & then corrects all the "production" settings & urls in the test DB.
Both my production & test databases live on the same server, but you could change the mysqldump settings to dump from a remote mysql server & restore to a local server quite easily.
Here are my scripts:
overwrite_test.coach_db_with_coache_db.sh
#!/bin/bash
dbUser="co*******"
dbPassword="*****"
dbSource="coach_production"
dbDest="coach_test"
tmpDumpFile="/tmp/$dbSource.sql"
mysqldump --add-drop-table --extended-insert --user=$dbUser --password=$dbPassword --routines --result-file=$tmpDumpFile $dbSource
mysql --user=$dbUser --password=$dbPassword $dbDest < $tmpDumpFile
mysql --user=$dbUser --password=$dbPassword $dbDest < /AdminScripts/change_coach_to_test.coach.sql
change_coach_to_test.coach.sql
-- Change all db references from #oldDomain to #newDomain
SET #oldDomain = 'coach.co.za';
SET #newDomain = 'test.coach.co.za';
SET #testUsersPassword = 'password';
UPDATE `wp_1_options` SET `option_value` = REPLACE(`option_value`,#oldDomain,#newDomain) WHERE `option_name` IN ('siteurl','home','fileupload_url');
UPDATE `wp_1_posts` SET `post_content` = REPLACE(`post_content`,#oldDomain,#newDomain);
UPDATE `wp_1_posts` SET `guid` = REPLACE(`guid`,#oldDomain,#newDomain);
UPDATE `wp_blogs` SET `domain` = #newDomain WHERE `domain` = #oldDomain;
UPDATE `wp_users` SET `user_pass` = MD5( #testUsersPassword );
-- Only valid for main wpmu site
UPDATE `wp_site` SET `domain` = #newDomain WHERE `domain` = #oldDomain;
Perhaps you are just looking for the wrong thing. Wouldn't a backup plugin handle this with ease? I know they exist for all the big CMS packages...
The two methods would be using the export/import feature under tools or copying the database. I email myself a copy of my production database weekly using the WordPress Database Backup plugin.
The import feature can be problematic for moving a wordpress blog as you have to configure your php.ini file often because the default value of files you can upload on a hosted php implementation tends to be too small by default.
I wanted to pull the database from my production wordpress website into an offline development copy of it on my desktop machine so I could modify the site and test it with a
full set of the existing blog content and history.
This proved to be problematic, as simply making an offline backup of the database and importing it into the local development database did not work.
Overcoming these problems in moving data from the production to the dev database can probably be used to go the other way as well - so I think you can just use these guidelines for what you want to do as well - just start with dev data and move it to prod.
The problems here were:
the permalink designations for the
blog posts are all stored in the
database as they would be for the
online version, but my offline copy
isn't at the domain address, instead
it is in the localhost directory. So
when I launch the site locally,
although the css formatting and
images are all in place (the image
links being relative), the actual
blog posts don't show up.
many of the links throughout the
site link back out to the internet,
so if you try to navigate to
archives, or comments, or
categories, or the main posts, you
get sent back out to the internet
instead of staying in the database
on the local machine.
To make sure I was doing this right, I blew away the wordpress install I had on my local machine and restarted from scratch.
Once I had a clean, new wordpress install and brand new default freshly created local database for it, I opened up the database in phpMyAdmin and took a look at the wp_posts
table. Inside there, each record (in other words, each post) has a column titled "guid", which shows the location of that post. For example, the first one in a fresh, default
install contains this "guid" value:
http://localhost/wordpress/?p=1
If you look in the wp_posts table of your online version, you'll see instead in this location the url to your site online.
You can't just import the tables wholesale into your local install, because you'll be importing all these outside references. It will make your local version impossible to navigate locally.
So, I created a backup copy of my online site's database and saved it locally as a .sql file. I then opened that file in a text editor (I used notepad++, a great piece of free software, but you could use any text editor). Things I needed to look out for:
For whatever reason, the tables on my
online site aren't just, for example,
"wp_posts" - they are
"wp_something_posts"... there are
some extra letters in there in the
table names.
Any references to http://... that contain my online url instead of localhost/wordpress
To keep it simple let's just do only the posts. In the backup copy of the .sql you've made of your online database, find the beginning of the wp_posts table. It will look something like this:
--
-- Table structure for table `wp_posts`
--
DROP TABLE IF EXISTS `wp_posts`;
CREATE TABLE `wp_posts` (
...and so on. Highlight everything above that up to just below the comment marking the beginning of the database at the top of the file (it will say -- Database: 'your database name') and delete it. Then go to the end of your wp_posts table, and delete everything after then end of it down to the bottom of the file. Now your file only contains your posts, and nothing else.
Save this as a separate document. Call it posts.sql or something like that.
Now, in this posts.sql file, you need to do two find/replaces actions.
Find every instance of the name of
the table wp_something_posts and
replace it with wp_posts. You only
need to do this if your backup copy
of your online database doesn't
match your clean local install as
far as the table names go. You want
whatever the table name is in this
file to match what your locally
installed wordpress database has as
this table name. If you don't make
these names match, you are just
going to end up importing the posts
into a new, differently named table,
which will be of no use to you at
all.
Find every instance of http://...
(replace the elipsis with your url)
and replace it with
http://localhost/wordpress (or
whatever the local url to your dev
version of the site is)
Now save this file again, to make sure you've got these changes set.
Now that you've done that, use phpMyAdmin to get into the wordpress database on your local machine, select the "import" tab and navigate the selector to the posts.sql file you just made, and then import it. This will pull all the data in that file into your local wp_posts table.
When that finishes, browse your local wordpress site. You'll see all your posts in there now. Hooray!
You may need to do something similar for a few other tables if you want to bring in your comments, tags, categories, and static pages you've created, etc.
I realize this is a convoluted process. There is probably a tool out there somewhere that makes this activity easier, and if someone knows of one I'd love to find out about it. If someone knows of a better way to do this manually than what I've described, I'd love to know that as well!
Until then, this is the way I figured out how to do it. Hopefully it helps get you going in the right direction.
You need to handle the serialized objects. Here is a client side HTML5 utility to handle it. Because it is all javascript, it's quite fast.
The alternative would be hooking a bash script into your deployment. So once the site is deployed, the db is backed up and deserialized with the new domain.
This about sums up the problems with the wordpress core architecture... but I wrote a plugin that solves the problems with domain names and absolute urls being stored in the database:
http://wordpress.org/extend/plugins/root-relative-urls/
This will solve the problems outlined by #oddbill. Though don't worry too much about the url being in the GUID column as that field is never used for link generation.
#markratledge provides a couple links to some lengthy documents that basically say this:
//export
mysqldump -u[username] -p[password] [database] > backup.sql
//import
mysql -u[username] -p[password] [database] < backup.sql
You'll want to exclude the comments/comments_meta tables if you push to production from staging so you don't lose all of your comments and trackbacks (#DavidLaing's approach will wipe those out.) And this assumes you only make content changes in your staging environment. If you want to make changes in production and your staging environment, you'll need to write scripts that sync the data instead of wholesale overwrite it... good luck on that task, may I suggest adding create & modified timestamp columns before you invest too much time with the current schema.
And finally, #RussellStuever's approach is suitable in most circumstances, just be sure to know when you are browsing your host mapped site versus your production site. And really be sure about it, because some browsers cache dns lookups for days until you physically close them and start a new process. At which point switching hosts may take some time, and switching frequently may get frustrating. And if you need to test with an iPhone, you'll need to publish the site live first, or use a good router that can remap outbound internet requests to local servers because you cannot modify hosts files on most mobile devices.
My plugin lets you develop and test from http://localhost/ or http://staging.server.local/ or http://www.production.com without any of the usual pitfalls. And then to migrate data, it's as simple as exporting and importing the data, no search & replace step or database setting tweaks necessary.
And don't rely on the import/export tool, it doesn't capture everything in typical wordpress installations, and still requires a needless search & replace step.