upgrade to 13.4 and ajax search issues

darren

Member
I have two issues

1. when performing a search using the easy search box it would always say error could not load result, when looking at the browser response i got this

[08] Error: during query execution.SELECT "id", "person" FROM "mail_list" WHERE (1 = 1) AND (COALESCE("person", '')) LIKE ('%' || :linked_field_filter || '%')) ORDER BY "person" ASC The DBMS server said: SQLSTATE[42601]: Syntax error: 7 ERROR: syntax error at or near ")" LINE 1: ...D (COALESCE("person", '')) LIKE ('%' || $1 || '%')) ORDER BY... ^

to Make it easier the problem is the trailing ')' at the end of the statement

so i noticed that there was a silent update, and thought it might be related to this issue and so i went through the update process and got this error

[08] Error: during query execution. CREATE TABLE "dadabik_user_entities" ( id_user_entity SERIAL, table_user_entity VARCHAR(128) NOT NULL UNIQUE, id_user_field_user_entity VARCHAR(255) NOT NULL, first_name_field_user_entity VARCHAR(100) NULL, last_name_field_user_entity VARCHAR(100) NULL, email_field_user_entity VARCHAR(100) NULL, sync_create_user_entity SMALLINT NOT NULL, sync_update_user_entity SMALLINT NOT NULL, sync_delete_user_entity SMALLINT NOT NULL, id_group_user_entity INT NOT NULL UNIQUE, FOREIGN KEY (id_group_user_entity) REFERENCES "dadabik_groups"("id_group") ON DELETE CASCADE ON UPDATE CASCADE, PRIMARY KEY ("id_dadabrain_query"))
The DBMS server said: SQLSTATE[42703]: Undefined column: 7 ERROR: column "id_dadabrain_query" named in key does not exist at character 635

so i cannot move forward with the update either.

On a side note, every time i do an upgrade I get a notice that i am using a version of postgresql that is too low for dadabik minimum 8.3 even though i am using 16.13

Any suggestions?

Your current DaDaBIK version​


You are using DaDaBIK version 13.3-Levanto enterprise, installed on Mar 10, 2026 the latest version of DaDaBIK is 13.4-Levanto released on Mar 18, 2026

You are not running the last release of DaDaBIK, the release you are running might have bugs and security holes, see the official change log for further information. You can upgrade DaDaBIK here.

In case you want to upgrade to a more powerful edition (from Pro to Enterprise/Platinum, from Enterprise to Platinum) please contact us.


System info​


PHP Version: 8.3.6


postgres version: 16.13 (Ubuntu 16.13-0ubuntu0.24.04.1)


Web server: Apache/2.4.58 (Ubuntu)


Client: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:148.0) Gecko/20100101 Firefox/148.0
 

eugenio

Administrator
Staff member
Hello Darren,
a couple of questions:
1) The search error message appears when you use the omnisearch bar, correct?
2) Is the search error message produced by a v13.3, before trying to upgrade?

I will look into the ugprade issue on Postgres, in the meantime I recommend to restore to v13.3 with a file+db backup.

Best,
 

darren

Member
question 1)

im not sure what the omnisearchbar is, so ill be more specific, its the search that is made when you have a select single field that is link to another field and it populates as you type

I think i found what it was though, it seems the upgrade defaulted the search to be "search as you type" "yes" as well as the "use ajax to load options" "yes" which when reading the help buttons, isnt compatible?

so i think ill have to go through my previous uses of the search functionality and change it over.

question 2)

the error was not produced when i upgrade to 13.3 though the normal upgrade was not working either, i had to use the alternative install method because of an error that was being produced when upgrading from v12 that you suggested using the alternative method, i do not recall the exact reasons. it was something about the php making reference to a function that was not in the upgrade unless you manually put it in yourself.
 

eugenio

Administrator
Staff member
Hello,
ok now it's clear which field type you are referring to but the problem is still unclear to me.

There are two problems:

1) Upgrade to 13.4 seems not to work

2) Search as you type seems not to work. About this, is the search error message produced by your v13.3, before you tried to upgrade to v13.4? Was it working in previous versions (v12)? I need to understand when exactly this problem appeared, if you have this information.


Best,
 

darren

Member
Hello,
ok now it's clear which field type you are referring to but the problem is still unclear to me.

There are two problems:

1) Upgrade to 13.4 seems not to work

2) Search as you type seems not to work. About this, is the search error message produced by your v13.3, before you tried to upgrade to v13.4? Was it working in previous versions (v12)? I need to understand when exactly this problem appeared, if you have this information.


Best,
1. yes the upgrade to 13.4 does not seem to work
2. i never upgraded to 13.4 it produced the error i mentioned before, and i tried upgrading because i was hoping the upgrade would solve the error that i was facing on 13.3. i did not have this error on v12

to put it shortly error on v12 = no, error v13 = yes
 

eugenio

Administrator
Staff member
I will investigate both the issues, but there hasn't been any change in v13 regarding "search as you type" and it does not default to "search as you type".
About compatibility, the help says it is not compatible with cascade drop-down fields.
The inline help also says:

If you use PostgreSQL, all your Lookup table linked fields must have a String data type (e.g. Varchar or Text) in your Database, otherwise the Ajax loading will not work correctly.

Does your db respect this?
 

darren

Member
i managed to upgrade to 13.4 by using the install.php method

the searches look to a citext column type is a string datatype, so yes it follows your requirements

In more detail:

my setup is a bit odd because it came from the earlier days of dadabik (think v6)

the setup is that it pulls the id from a view and the user searches a column which itself it a concatenated version of other columns

e.g. concat(cats.cat_name, ' - ', microchip_num.microchip)::citext

now since postgresql by default is case sensitive, citext was used to make the column case insensitive since i dont have the ability to alter the behavior of the search box functionality.
 

eugenio

Administrator
Staff member
Hello,
the fact that the original installation was old doesn't matter. I am still confused, does the search as you type problem always appears? Could you try to create a simple table with two varchar fields (no citex) and see if the error is triggered?
Are you sure this worked in v12 or maybe in v12 you did not enable search-as-you-type?
 

darren

Member
i will try to make a temp table to do what you ask,

i cannot confirm if both options were selected when i upgraded to v12

the "use ajax to load results" doesnt do anything only the "search as you type" in fact the "search as you type" button does what the ajax button did, i dont see a difference really. yet when both are selected it gives the error i described above.
 
Top