CiviCRM Community Forums (archive)

This occurs after I hit 'Confirm' on a paid membership registration page, instead of redirecting to the Thank you page, I get a 'DB Error: syntax error'. It appears to process the payment and the membership correctly. It looks like the error is around civicrm_membership_type, but I can't figure out what it means.
The Error is pasted here: http://pastebin.com/wQAVkDta 
the BackTrace is pasted here: http://pastebin.com/dkw8tG0s

I re-installed the version I was on 4.5.4, and it gave me the same error. I then upgraded to 4.5.6 to see if somehow there was a bug that had been fixed, and I still get the same error. Not sure where to go from here, I've used up my bag of tricks (which isn't very big admittedly)

Please post screenshots of the a) Membership tab of your Contribution page configuration and b) the MembershipTypes screen in Administer.

There's no limit to the number of membership types that I am aware of, other than the natural limits on human comprehension.   That's quite a list.  I suggest reaching out to www.civicrm.org/providers for paid help.  I don't think you're going to come to a resolution (or at least not a quick one) on the volunteer part-time support forums. 

It does appear that the number of membership types is what triggers this error. It seems to be somewhere around 30 that sets it off, although it was inconsistent. Fortunately it means I can avoid the error by reducing the number of membership types- I'll just have to find another way to reflect the accounting side of it.

We basically have four membership levels that break down into a national, local, and online memberships at each of the levels. Since some members like to pay the annual membership all at once and some like to pay in monthly installments, I had to create different membership types for the annual price and for the monthly recurring payments (otherwise the recurring payments would charge the annual membership price every month!) This is what led to about 20 different membership types.  To make this cleaner for the user, I used membership price sets and jQuery to create logic so the user only has to select one of the four membership levels, and depending on which level they select and whether they choose recurring billing or not, the appropriate sub-membership types (which are hidden from the user) are selected. This worked well until I started getting this DB error. There were some extraneous testing membership types sitting around which I've since gotten rid of, but it's a bit disconcerting to be pushing it so close to breaking.

I was curious to see whether this was a problem with something I did on my installation, or whether it was a limitation in the code itself. I tested it out on the demo site and was able to recreate the problem (sort of).

On my site the DB error occurred when the user confirmed their membership registration on the front end. However on the demo site, the DB error occurred in the back-end when I created over 20 membership types. Specifically when I tried to edit the membership tab of the contribution page.
I just opened a bug report on the issue here:
https://issues.civicrm.org/jira/browse/CRM-16018

You might ask why anyone would need over 20 membership types...
I mentioned in the post above about our membership break down- the main factor that led to so many types was having to duplicate every membership type to account for whether the member wants to pay once for the annual membership, or break it up into monthly installments. So every membership option actually has a monthly membership type in which auto-renew is required, and an annual membership type where auto-renew is an option.

I thought about doing this in a price set- just selecting the same membership type twice and then changing their price in the price set to reflect the monthly and annual membership prices. Then I'd use jQuery to select the appropriate option depending on whether the user selects recurring payments or not. The problem with this is that monthly membership needs to be auto-renewed, but I want to give them a choice on the annual.

If anyone has any ideas on how to accomplish this differently- in a way that doesn't break the system with too many membership types, I'm all ears.