easiest way to move to production server?

[shrill]

Hi all. I apologise if this has been asked before I'm just wondering if this would work to get my civicrm onto my live server (it is currently running fine on my test server and I haven't installed any external modules)

1) Create database for Civicrm on production server
2) Install Civicrm on production server
3) Data dump from Civicrm database using phpmyadmin
4) Import data into Civicrm production database


Is it really that easy, or will I probably run into difficulties doing it this way?

I'm using Drupal 5.14

Thanks,

Shrill

[Donald Lobo]

Is your drupal user table the same between test and production? if not, i'd also do the following:

5. truncate civicrm_uf_match

Once installed you can run synchronize users to contacts or let it happen organically. in addition to the other steps also do:

6. truncate civicrm_menu
7. update civicrm_domain set config_backend = null;
8. truncate sessions table from drupal database

lobo

[shrill]

Thanks Lobo.

Yes it is the same. I haven't yet synchronized the users because I haven't yet imported the users. When I do that, I'm going to want to send them emails (a la Drupal user import module) with passwords etc., so I thought it would make more sense to have the bare bones site working on the live site, then do some test user imports on the test site, and do the same on the live site (but with the real users). Or does that make sense?

I'm not really a database person, my limited experience so far is with my current Drupal site (pre civicrm). How does one truncate civicrm_menu etc? Do you just drop the table in phpmyadmin? Or is that a setting in the settings file?

Thanks,

Cheryl

[Donald Lobo]

1. starting bare bones etc on test site followed by live site is fine and makes sense

2. "truncate" is a sql command. It empties the table but does not drop the table. So you can run the queries using PMA from the SQL Query tab, The two commands to run are

in the civicrm db:

truncate civicrm_uf_match;
update civicrm_domain set config_backend = null;

and in the drupal db:

truncate sessions;

[shrill]

1. starting bare bones etc on test site followed by live site is fine and makes sense

2. "truncate" is a sql command. It empties the table but does not drop the table. So you can run the queries using PMA from the SQL Query tab, The two commands to run are

in the civicrm db:

truncate civicrm_uf_match;
update civicrm_domain set config_backend = null;

and in the drupal db:

truncate sessions;

Excellent! Thanks!

[shrill]

1. starting bare bones etc on test site followed by live site is fine and makes sense

2. "truncate" is a sql command. It empties the table but does not drop the table. So you can run the queries using PMA from the SQL Query tab, The two commands to run are

in the civicrm db:

truncate civicrm_uf_match;
update civicrm_domain set config_backend = null;

and in the drupal db:

truncate sessions;

Hi again.


Okay, so I tried this tonight. Mostly it worked okay (civicrm installed fine), but when I went to import the data from my test server using phpmyadmin I got the following error:

Code: [Select]

Error

SQL query:

--
-- Database: `my_membership`
--
-- --------------------------------------------------------
--
-- Table structure for table `civicrm_acl`
--
DROP TABLE IF EXISTS `civicrm_acl` ;

MySQL said: Documentation
#1217 - Cannot delete or update a parent row: a foreign key constraint fails

Thoughts?

Thanks!

[yasheshb]

Hi.

 This may work for you

http://dev.mysql.com/doc/refman/5.1/en/innodb-foreign-key-constraints.html

------------------------------------------------------------------------------------------------------------------------------------
 When performing foreign key checks, InnoDB  sets shared row-level locks on child or parent records it has to look at. InnoDB checks foreign key constraints immediately; the check is not deferred to transaction commit.

To make it easier to reload dump files for tables that have foreign key relationships, mysqldump automatically includes a statement in the dump output to set foreign_key_checks to 0. This avoids problems with tables having to be reloaded in a particular order when the dump is reloaded. It is also possible to set this variable manually:

mysql> SET foreign_key_checks = 0;
mysql> SOURCE dump_file_name;
mysql> SET foreign_key_checks = 1;

This allows you to import the tables in any order if the dump file contains tables that are not correctly ordered for foreign keys. It also speeds up the import operation. Setting foreign_key_checks to 0 can also be useful for ignoring foreign key constraints during LOAD DATA and ALTER TABLE operations. However, even if foreign_key_checks = 0, InnoDB does not allow the creation of a foreign key constraint where a column references a non-matching column type. Also, if an InnoDB table has foreign key constraints, ALTER TABLE cannot be used to change the table to use another storage engine. To alter the storage engine, you must drop any foreign key constraints first.
------------------------------------------------------------------------------------------------------------------------------------

hth.

yashesh

[fen]

I'm not sure if it's required, but if there was a CiviCRM installation there previously I get a certain peace of mind by also running (from the command line in the Drupal directory):

Code: [Select]

rm -rf files/civicrm/templates_c/*
as well as truncating all the Drupal cache* tables.

[Denver Dave]

You might test to make sure that you can import your phpmyadmin export with phpmyadmin.  I'm pretty sure I can not load in less than my server's limitation of 30 seconds, although I have not tried. 

For a similar situation with the phpBB discussion forum, I used a utility called big dump that divides the import into segments.

[shrill]

I'm not sure if it's required, but if there was a CiviCRM installation there previously I get a certain peace of mind by also running (from the command line in the Drupal directory):

Code: [Select]

rm -rf files/civicrm/templates_c/*
as well as truncating all the Drupal cache* tables.

Thanks very much.

I'm still having this difficulty. At the moment I only have access to PHPMyadmin. Any ideas? At the moment I'm only able to update the database by dropping the entire database and then importing which isn't really an option now as the live site is now being used.

Thanks again,

Shrill

[andro01]

sorry to bump this topic. But I have moved my civicrm site to another site. It gives the following error and will not open any civicrm screen:

warning: file_exists() [function.file-exists]: open_basedir restriction in effect. File(/home/deb7651n2/domains/kyudo-renmei.com/public_html/sandbox/sites/all/modules/civicrm/packages/IDS/default_filter.xml) is not within the allowed path(s): (/home/shiseikan/:/tmp:/usr/local/lib/php/) in /usr/home/shiseikan/domains/shiseikan.nl/public_html/sandbox/sites/all/modules/civicrm/packages/IDS/Filter/Storage.php on line 201.

The first line still has references to the old user and site. The second one seems to have the correct user and site. So I am wondering what setting I missed. Where does civicrm still get the old reference from?

[Donald Lobo]

check:

http://wiki.civicrm.org/confluence/display/CRMDOC/Moving+an+Existing+Installation+to+a+New+Server+or+Location

for instructions on moving a site. Please ensure that you follow ALL the steps listed there

thanx

lobo