CiviCRM Community Forums (archive)

When I try to do the upgrade with "?q=civicrm/upgrade&reset=1", I get the message  "CiviCRM 4.3.0 requires MySQL trigger privileges".

upgrade 4.29 to 4.3
MySQL 5.5.24-log with trigger privilege checked for the civicrm user
Apache/2.2.22 (Win32) PHP/5.4.3
Drupal 7.22

When I do the test (CREATE TRIGGER civicrm_domain_trigger BEFORE INSERT ON civicrm_domain FOR EACH ROW BEGIN END) in phpmyadmin it works.

In the upgrade script the code in core/dao is executed with the result "DB Error: unknown error" as result for the create trigger. (Own display added)

The test in phpmyadmin is with the user root, but adding GRANT to the civicrm user does not make a difference. For root I have (global) users for the machines: localhost, 127.0.0.1 and ,,1. For the (database specific) civicrm user I have only localhost.

Hi all,

I am having a similar issue. The upgrade to 4.3 said that CiviCRM requires trigger privileges. We checked with our hosting company and we have been assured that we have those privileges. Here is some info:

PHP Version:  5.3.18
Joomla! Version: 2.5.9
Database Version 5.5.28-log

error:

Sorry but we are not able to provide this at the moment.
CiviCRM 4.3.1 requires MySQL trigger privileges.

As a side note, we were hoping to test our mobile app in the 4.3.0 environment, but have been unable to do so since we can't figure out how to get past this issue.


-Ricky

i read these reports in the upgrading to 4.3 thread. i observed this (the trigger failure) in a fresh install, not as an upgrade.

details:
FreeBSD 9.1-STABLE
PHP: 5.4.10
MySQL: 5.5.30-ndb-7.2.12-log
drupal: 7.22
CiviCRM: 4.3.3, drupal, ce35dedb59

when the civicrm user is not root, the trigger error is present, as others have reported upgrading.
when the civicrm user is root, the trigger error is not present.

this behavior is present in both the 4.3.2 and 4.3.3 install steps.

Tjis is another 'me too' scenario.
This request fro privileges on upgrade - it it a feature of 4.3 or a bug

If its a feature bang goes your wordpress marketshare who wil mostly not be able to run stuff on shared hosts.

Be great to clarify if this is intende behaviour or not. It doesn't sound like it is from Lobo's responses thus far

This is also making CiviCRM a much more complicated install than WordPress users are use to- one of the beauties of WP plugins is that they just work.
We've got 3 instances of Civi on our own dedicated server. We've been able to successfully upgrade 2 of them- once we figured out a few things:

• Our new server had the default database engine switched to iSAM and we had to switch back to INNODB
  We had to set the trigger permissions manually via WHM for Administrator (it's our server- and we have this ability- as pointed out, many individual users on a shared server may not)

We're still working on figuring out if the third install doesn't have the correct root user somehow- or the user was changed- or pw change made things go wonky.
We're tempted to do a clean install- and export all the civi data- and then reimport it into a brand new db- with slightly different mapping- but are afraid this may be a gargantuan task.
We'd like some suggestions on how we determine where the root user instances are that could be messing this up- so we can try to match them all up-
and- we'd also like to know if anyone has some tips for remapping existing data into different fields?
We originally imported a voter database and recreated the exact fields of that db- instead of pointing some of them to Civi's built in fields - oops.

Thank you

We were able to get this to work on a shared server with Cloudaccess.net. They have reasonable pricing and phenomenal support if you're a Joomla user.

Finally got the upgrade to complete-
but- first- got error pages like this when we did anything- or tried to donate-

} $status = CRM_Member_BAO_MembershipStatus::getMembershipStatusByDate( CRM_Utils_Array::value('start_date', $currentMembership), CRM_Utils_Array::value('end_date', $currentMembership), CRM_Utils_Array::value('join_date', $currentMembership), $today, TRUE ); if (empty($status) || empty($status['id']) ) { CRM_Core_Error::fatal(ts('Oops, it looks like there is no valid membership status corresponding to the membership start and end dates for this membership. Contact the site administrator for assistance.')); } $currentMembership['today_date'] = $today; if ($status['id'] !== $currentMembership['status_id']) { $memberDAO = new CRM_Member_DAO_Membership(); $memberDAO->id = $currentMembership['id']; $memberDAO->find(TRUE); $memberDAO->status_id = $status['id']; $memberDAO->join_date = CRM_Utils_Date::isoToMysql($memberDAO->join_date); $memberDAO->start_date = CRM_Utils_Date::isoToMysql($memberDAO->start_date); $memberDAO->end_date = CRM_Utils_Date::isoToMysql($memberDAO->end_date); $memberDAO->save(); CRM_Core_DAO::storeValues($memberDAO, $currentMembership); $memberDAO->free(); $currentMembership['is_current_member'] = CRM_Core_DAO::getFieldValue( 'CRM_Member_DAO_MembershipStatus', $currentMembership['status_id'], 'is_current_m
Fatal error: Class 'CRM_Member_BAO_Membership' not found in /home/username/public_html/wp-content/plugins/civicrm/civicrm/CRM/Member/BAO/Query.php on line 38

Then ran repair cache - and now- no civimenus at all in the Dashboard- no ribbon at the top.
Any suggestions?

Am trying to upgrade a client's site which is on a host that is not providing mySQL trigger access to their clients.  However it sounds like they will run the triggers for the client if provided information on what the triggers are that need to be run.  I of-course do not know what they are:  Could I possible get a list, or documentation of what triggers need to be run, to pass on to the hosting company?

We go into cpanels whm-
to PHPmyAdmin
select> users
pick the database user- for Civi- and edit privileges
under admin- make it "super"

on one install- the one from hell, that keeps us miserable- it also required us to go to "Structure" and select "trigger" before the update would complete.
This wasn't needed on the other databases.

hope this helps.