Repeat Group MySQL Error 1241

[davez]

I'm getting a MySQL error with a repeat group:

1241 Operand should contain 1 column(s)

Here's how to replicate.

1. Create a record with 3 or more repeat group items (in the join)
2. Go back in and edit that record. Delete a middle item. Not the last repeat group item.
3. Save that record and the error will occur.

The table/list I'm testing is fairly complex.

 

[davez]

I'm testing on different table with a repeat group and am getting strange effects. (Not a MySQL error.) This repeat group (that's freaking out) is a databasejoin with a cascadingdropdown. Freaking out in this case means: If I delete a middle item, the final item's databasejoin and cascadingdropdown goes null and 0 respectively. I see that 2 days ago cheesegrits fixed a countable issue in repeat counting. Maybe that will fix the issue. I'm working on a live site, so I hate to install the latest build.

 

[davez]

I took the risk and updated with the latest. The problem is still there.

I've tested on a simple joined repeat group. The repeat group has databasejoin and cascadingdropdown. If I delete the last item (lowest), it works fine. If I try deleting a first or middle item it deletes one but messes up the databasejoin and cascadingdropdown content (sets to null and 0).

For my more complex repeat group, I'm still getting the MySQL error, "1241 Operand should contain 1 column(s)."

A bit more information. This bug must have been introduced within the past year. I updated this site just recently with Fabrik 3.9. It had been Fabrik 3.8 (I'm not sure how long).

UPDATE: I created the most simple repeat join possible and the problem is occurring there as well. Basically, if there are three or more repeats, it deletes one and then sets the non-pk items and pk_link to 0 or null to the last item.

I'm a wee-bit nervous about this bug, because I use a lot of repeating group/joins.

 

[startpoint]

I can't replicate this error without cascadingdropdown. Try to disable cascadingdropdown element and look databasejoin value.

 

[davez]

I can't get the MySQL error to occur, except on my more complex page, but because repeat groups aren't working properly on edit, that's the first place to hunt for the error.

The problem is still occurring no matter what the fields are. On my most simple example as noted above:

• Edit a record with 3 or more joined records in a repeat.
• Delete the last and/or middle item.
• Check data storage.

It doesn't store the middle record properly. Or if two are deleted, it deletes one and removes the data from the fields of the middle one.

Looks like it might relate to this: https://github.com/Fabrik/fabrik/commit/c5960e2f32025e2ce596e4c665ba2208d1c7f59d
However, I went back to the build just for that commit and the error still occurs.

 

[davez]

I can't find anyway to donate any longer to get standards support assistance.

Friendly bump.

 

[troester]

There's no longer standard or pro support via forums.
You may ask @mediaateam for a quote.

I can't replicate your issue with a dbjoin and a ccd in a repeat group. Deleting the 2nd group of 3 is working correctly.
Are you using the "recommended" primary key as value?

 

[davez]

Here's my simplified test:
https://permits.scci.org/test

I removed the CCD and it still has the same issue. The second is deleted and the data is wiped for the 3rd item. Yes, the primary key is the value being stored.

 

[troester]

I can see it on your test site but can't replicate.
The joined records don't seem to have an order. Maybe it will help to define one (in list settings set 1st order to e.g. the id of the main list, 2nd the id of the repeat list).

 

[davez]

That did it, adding an order to the joined table fixed it, at least for this iteration of the problem. Now I need to go back into the original bug to see if that helps with my MySQL error.

 

[davez]

Okay, I'm still getting the MySQL error, but I need to figure out how to replicate this in my test table.

 

[davez]

Well, this is a crazy little affair.

I have learned that my MySQL error is simply a side effect/symptom. So, once the repeat group issue is resolved, it won't be a problem.

I've found that setting the order on the repeat group wasn't actually resolving things. I also found that disabling caching for the table helped on my test table. When not disabled, it was causing trouble.

But I can't get it be fixed on my non-test table. I've even pulled the whole thing over to a dev site, so I can turn off just about everything, except the most simple join. Even deleted all the extraneous fields. Still it is consuming one row when edit on save for a repeat greater than 2.

 

[davez]

It looks like the issue also has to do with my custom template. For some reason, it no longer works with a repeated group.

 

[cheesegrits]

I can't replicate this, and if it was a systemic issue, we'd see lots of people reporting it. So yes, most likely an issue with your template.

If you can point me at a test page exhibiting the issue, I'll take a look.

 

[davez]

Yes. It was my custom form template that was causing all the trouble. I had been using it for a few years and with the latest update it no longer was happy.

Using the normal bootstrap template I did discover some oddities, as noted by Troester, such as when I didn't have an ordering set in the main table, the repeat group/join would botch on edit save (if a joined record was deleted). I also had some weirdness connected to the Disable Caching feature when I was testing that on a normal template. But if nobody's complaining, then we can call it good.

Thanks for checking in.

 

[davez]

Closing thread...