It sounds as though there is either a cached path to ClassLoader.php somewhere or there are two copies of the CiviCRM code under your modules directories. Various scenarios and solutions are discussed in this forum post: svn installation says "Cannot redeclare class CRM_Core_ClassLoader" Please post back here rather than on the forum, though.
If you're sure ...
CiviCRM defines MySQL triggers for certain tasks. When you use phpMyAdmin, mysqldump or similar to export your database to a text file, it exports your triggers as well. The format is something like this:
/*!50003 CREATE*/ /*!50017 DEFINER=`newpress`@`localhost`*/ /*!50003 TRIGGER civicrm_address_after_insert after insert ON civicrm_address FOR EACH ROW ...
To add to Erik's, here are three advantages to separating the databases:
1) Upgrades. When we are working to upgrade Civi, I know that the website side of the house is largely unaffected (not completely unaffected, but mostly), and if something in the upgrade goes awry, I'm only having to deal with the Civi side of things (especially in the event of ...
Jon G's answer is correct.
However, If you're not in the world of shell editors and perl, you can also open the dump file in a text editor (not a word processor) and do a search and replace. You can just search for DEFINER=namename@localhost portion, replace it with nothing, and leave the rest of the line in place.
There are multiple "gotchas" when relocating a working CiviCRM install. (CiviCRM's wiki page on Moving an Existing Installation to a New Server or Location is seven pages printed out!) Here's what we watch out for when moving sites.
CiviCRM stores filesystem paths in various locations in the DB, which can cause a restored DB to not ...
My standard practice is still to have them separately simply because I prefer the overview as a developer. And obviously you have to make sure the backup is OK, but if they never checked that (or tested it) I would see that as a bigger issue than having it in one database :-)
If you TRUNCATE the table, be sure you do so at a time when there are no in-process contributions or other users actively filling out a form or their submission will be lost. Otherwise, it's safe to do so.
Your backups can just skip that table, no need to back it up. Although you do need to get the structure of the table in order to be able to restore a ...
How to revert the CiviCRM to previous state:
Put Drupal into maintenance mode
Disable integration modules
Replace civicrm.settings.php with backed up copy and check permissions
Remove everything in <drupal_home>/sites/all/modules/civicrm and
replace with backed up version and check permissions
Drop civicrm database and import backup database
I would suggest to perform deletion of contact from UI and then reseting the auto increment value through mysql command. Truncating database might loose contact that are not suppose to be deleted like logged in contact id or Default organization contact id or they might be possible to have orphan data for contacts if we directly truncate the table. Here is ...
One great way to shrink the backup is to only backup the bespoke bits (e.g. custom extensions and themes) and the database, not the actual Joomla! and CiviCRM code files that are freely downloaded from elsewhere.
This depends on you not having edited any core files, which your developers shouldn't be doing anyway.
I use separate database whenever possible, for a few reasons, many of which Allen already covered. In addition, I am often responsible for migrating data to a new CiviCRM installation while a coworker (or another dev shop) is responsible for CMS implementation. This allows me to give frequent updates to the client on a test server without coordinating with ...
Best to exclude its content from your backups. You can dump a table's structure only with mysqldump --no-data
As Coleman points out, form data is persisted there while a multistep form is being used, so using TRUNCATE will invalidate any forms currently being processed.
You might want to review why your civicrm_cache has grown to this size - check the ...
One answer to your question is that you can use the sql-dump drush command to dump your civicrm database by using this option:
--database : The DB connection key if using multiple connections in settings.php.
For that to work, you'd have to edit your drupal settings file to include something like:
$database['civicrm'] = array('default' => array('...
There is a known issue (Too many connections in backup_migrate_source_db->_get_db_connection()) with recent versions of Backup and Migrate from 3.3 onwards which prevents CiviCRM from backing up as well is Drupal. If you use version 3.3 or later it is likely that you will not be able to backup the CiviCRM database as well as the Drupal database. However, you ...
You can also get this error if you do something (ahem) really confused like have two copies of your Drupal site on the same machine that both point to the same CiviCRM codebase/database.
Of course you'd have to be stupid to do that. *blush*
I had the hard-coded strings in my civicrm.settings.php file pointing to paths in the other Drupal codebase. Just ...
Try this (Drupal) :
1) Comment following lines in civicrm.settings.php :
2) Take backup of variable table in database & delete the row with name = 'civicrm_class_loader'.
3) With this your civicrm page should get loaded.
4) Now clear civicrm caches or hit "...
If you're getting a Fatal Error: Cannot redeclare class CRM_Core_ClassLoader in /sites/all/modules/civicrm/CRM/Core/ClassLoader.php, line 36
sudo -u apache drush status
will also result in a Fatal Error - and you will also not be able to run:
drush vset civicrm_class_loader ''
You're definitively looking for multicode bases: perhaps you're ...
The simplest route I believe is to generate DB dumps which omit these triggers by using mysqldump's --skip-triggers switch
mysqldump --skip-triggers NAMEOFDB > NAMEOFDB.sql
This outputs a version of the DB dump without triggers, which CiviCRM will regenerate once loaded onto the next site.
If you're using another interface to mysqldump, eg phpmyadmin ...
I would bet almost 100% that you're using drush 7 or higher. The function drush_sql_dump_execute doesn't exist in drush 7. Support for drush 7 was added as of CiviCRM 4.5.5 - see CRM-15567.
That link suggests that drush 6 has the same problem. I would recommend using mysqldump until you're upgraded.
1/ unlikely to be upgrade related
2/ assuming you have access to 'log' tables you can write an sql query to identify records where the first/last names have changed from the previous log record
3/ if you mean how to find and prevent in future, use the logs to try and identify who/when and figure out what the person was trying to do and train them otherwise ...
problem was to backup the joomla, civi site because of the huge number of files; so backup with ftp (httpdocs) and database sql with phpmyadmin took several hours
so I tried akeeba free backup, extension for joomla; this works fine and fast on the server itself and I can downlad the akeeba .jpa file (70 MB) also very fast with ftp (downloading over browser ...
Yes, that is approximately the number of files. And when you make a code base backup, you have to copy them all. What is the backup method you are using? If your only option is to copy them with (s)ftp transfer this can take a lot of time. But if you have ssh access to the system use zip or tar to pack all these files together, and copy just this single file....
If you run drush civicrm-sql-dump --help the output is:
Prints the whole CiviCRM database to STDOUT or save to a file.
drush civicrm-sql-dump Save SQL dump to the directory above Drupal root.
--data-only Dump data without statements to create any of the schema. ...
Strange, we had an issue on 4.6.24 just now.
The CiviCRM log file stated: -
DB Error: constraint violation
The debug information should give you the MySQL table name. For some reason, a custom table (civicrm_value_tablename_id) was linked by foreign key (entity_id) to the wrong table. In my case, it was the civicrm_event table, whereas it should have been ...
One more thing further to the answers so far: moving to a different CMS. If, for whatever reason, you want/need to move civiCRM to a different CMS this is quite simple if the databases are separate. I've done it, so don't say it will never happen.