SOLVED - Error 1054 Following Fabrik Upgrade

nclaypool

Member
Hello.

Today I upgraded Fabrik from 3.5.1 to 3.6 following this upgrade two of my forms would spit out an error when saving new or modified records.

The error message states
1054 Unknown column 'Array' in 'where clause'

Thinking this had to do the Form I disabled all form plugins, same error. I've got lots of forms on this site and the rest are still saving without fail. The one particularly unusual aspect of these two forms is that they've got a repeating table in them while the others do not. In fact, each form has two repeating groups attached to it. One for simple data, the other for attachments. I unpublished both repeating groups in one of the forms and it started saving, I enabled the attachment group, it also still saved. Only when i re-published the simple data repeating group did the error return.

When I look at the list's join information everything looks fine, in fact none of it has changed from what I can tell. Tried turning on debug to get more info on the error but it displays no extra info.

Thanks for any guidance!
 
I thought maybe it was a PHP version issue so I tried bumping up to 7.0, this produced a different error so I reverted back, cross that bridge after figuring out what's happening here.
 
I have it narrowed down to what elements are causing the problem.

On the repeating group for the purchase order items there are a series of four databasejoin menus that display account codes. If I unpublish all four the error disappears. Any one turned on and the error returns.
I had some text in the "data-where" tab and removed that but it still errored out. I also had one validation setup, I tried turning that off as well, still errored out.
 
Slight correction, the elements that are causing this are calc fields

Their entire purpose is to take the ID of the selected account from the databasejoin menus then run a query to match that ID with the actual account code, this is for the purposes of displaying in printed purchase orders. The code is as such.

PHP:
$gl_raw = '{purchase_orders_30_repeat___gl_account_raw}';

$db = JFactory::getDbo();
$query = $db->getQuery(true);
$query
  ->select('code')
  ->from('gl_accounts')
  ->where('id = ' . $gl_raw);
 
$db->setQuery($query);
$gl_code = $db->loadResult();

return $gl_code;

My guess is based on the error that the $gl_raw is turning into an array when it should just be getting a single number.
 
I can confirm that with the (int) added and having it spit out the values of the variables that the variable being used to run the query is getting a value of zero. Resulting in the output variable having a null value.
 
I disabled those faulty CALC elements again and changed my print article to just use what I thought would be the labels from the accounts. Turns out what it's receiving is the raw IDs. So I'm going to rewrite my code that assembles the print list on the purchase order article so that it takes those IDs and uses them to pull the actual account numbers.
 
That appears to have worked, and at the same time, simplified the structure a bit.

What I did was unpublish the CALC fields on my repeating table that was causing the error, since I could capture the raw IDs of those account codes I just used those and moved where my queries pulled the actual account codes. Not sure what the problem was with the others but they're no longer needed.
 
Yes, join values will usually be arrays. I usually put in a little failsafe ...

$myValue = is_array($my_value) ? $myValue[0] : $myValue;

Also, quote your values in the query, in case they are empty ...

->where('foo = ' . $myDb->quote($myValue))

-- hugh
 
Yes, join values will usually be arrays. I usually put in a little failsafe ...

$myValue = is_array($my_value) ? $myValue[0] : $myValue;

Also, quote your values in the query, in case they are empty ...

->where('foo = ' . $myDb->quote($myValue))

-- hugh

Good advice, thank you for the guidance!
 
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top