ran into trouble upgrading from 11.2 to 11.7

[dh]

Not asking for support, but just reporting a potential problem. If I'm correct, documentation should be adjusted to reflect a warning.

I ran into a [08] MySQL error on doing the up.php method trying to take 11.2 to 11.7. I didn't retain the specific error messages involved, but I know that I was not able to recover by switching the "old" upgrade method. In the end, I decided the errors were unrecoverable, and I'm simply going to have to do a clean install of that particular instance.

My theory is that changes made to the DaDaBIK user tables design in 11.6 are the issue. In the other instances I have running, I will upgrade first to 11.6 before going to 11.7. Wish me luck!

 

[eugenio]

Hi,
you don't need to go through an 11.6 upgrade before upgrading to 11.7. You can upgrade any DaDaBIK >= 5.0 to 11.7 without intermediate steps.

If you don't remember the error message, I can't say what happened.
The old upgrade method is just an alternative upgrade method, it can't fix errors.

Best,

 

[dh]

Hi,
you don't need to go through an 11.6 upgrade before upgrading to 11.7. You can upgrade any DaDaBIK >= 5.0 to 11.7 without intermediate steps.

If you don't remember the error message, I can't say what happened.
The old upgrade method is just an alternative upgrade method, it can't fix errors.

Best,

OK, tried again on another instance and had the same problem:

(1) First time running up.php I got a javascript "error" box with no detail. After clicking it, I'm taken to up2.php. But (after checking consent boxes) this second script just hangs.

(2) I then refreshed the page and took the restart option. When I ran the script again I got

"[08] Error: during query execution. ALTER TABLE `dadabik_univlist_forms` ADD label_grid_field VARCHAR(500) NOT NULL DEFAULT '' The DBMS server said: SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name 'label_grid_field'"

This likewise seems to be unrecoverable. However, restoring the backed up folder for the instance seems to have restored functionality, without restoring the database so no harm was done. Wish I'd tried that on the first instance that failed!

Both instances with the problem have been plain vanilla, running fine before the upgrade attempt.

 

[eugenio]

Hello,
the problem 2) probably occurs because the first attempt already altered your DB so the field was just there.
We have to solve the problem 1), can you post a screenshot of the error (please open the browser console before starting, so we can see the JS errors)?

I don't think I have understood the second part of your message. If you want to restore the previous situation you always have to restore files + DB.

 

[Martin]

Hi,
I have the same problem when trying to update to 11.7.
Also got an „error“ pop-up and then all the same as user dh.

Could you find a solution in the meantime?

BR
Martin

 

[dh]

Hi,
I have the same problem when trying to update to 11.7.
Also got an „error“ pop-up and then all the same as user dh.

Could you find a solution in the meantime?

BR
Martin

No, not yet. Despite Eugenio's statement, I did not need to restore the database to have functionality. Just restoring the folder containing the DaDaBIK instance gave me a working interface. However, trying to reproduce the error gave me literally nothing on the browser console -- just the error box.

I still wanted to move ahead with the version updates so that I can move on to php8, and so I attempted a database restore, which got me into additional troubles that have nothing to do with DaDaBIK. So I'm afraid I got sidetracked by these problems, and I haven't yet had a chance to return to the updating. I should be in a position to try again soon.

 

[Martin]

No, not yet. Despite Eugenio's statement, I did not need to restore the database to have functionality. Just restoring the folder containing the DaDaBIK instance gave me a working interface. However, trying to reproduce the error gave me literally nothing on the browser console -- just the error box.

I still wanted to move ahead with the version updates so that I can move on to php8, and so I attempted a database restore, which got me into additional troubles that have nothing to do with DaDaBIK. So I'm afraid I got sidetracked by these problems, and I haven't yet had a chance to return to the updating. I should be in a position to try again soon.

Hi,
if you found a solution, it would be much appreciated if you let me know. I’ll do the same…

Ps:
I’m running dadabik in a Ubuntu 20.04.5 LTS VM.

 

[deep64blue]

Despite Eugenio's statement, I did not need to restore the database to have functionality. Just restoring the folder containing the DaDaBIK instance gave me a working interface.

I would be very careful with this, you may struggle with future upgrades if there is something not quite right somewhere.

 

[dh]

Hello,
the problem 2) probably occurs because the first attempt already altered your DB so the field was just there.
We have to solve the problem 1), can you post a screenshot of the error (please open the browser console before starting, so we can see the JS errors)?

I don't think I have understood the second part of your message. If you want to restore the previous situation you always have to restore files + DB.

Well, after a complete database restore, I have tried again. This time, no error box. However, still getting the same [08] error message as originally reported above. The browser console is completely uninformative.

When I check the table referenced in the error message, it is *not* correct that the named column already exists -- it simply does not.

Then if I try and reload the instance before doing any restoration of anything, I get the message

[08] Error: during query execution. SELECT `id_user`, `id_group`, `ids_group_others`, `username_user`, confirmed_timestamp_user FROM `dadabik_univlist_users` WHERE `username_user` = 'public_user'
The DBMS server said: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'ids_group_others' in 'field list'

In this case it seems to be correct that this column does not exist in the users table.

The only other thing I can think to add is that when I began the upgrade process, I was the public user. Not logged in as root or any other named user.

Do I now have any alternative except fresh installation of DaDaBIK in this instance?

 

[dh]

Actually, no need to reply. I've convinced myself that I must do a clean install of this instance. There must be something badly corrupted in my DaDaBIK tables, and it must have been that way before I began the upgrades.

After I get back in business with this instance, then I have four more instances that I'll try the upgrade procedure on, and maybe I'll have better luck with those.

 

[dh]

Successful clean install with 11.7 on the first instance.

FWIW, the installer complained about tables in my database with non-allowable characters in field names and a couple with missing primary keys and declined to install those tables. I was able to fix all this and install the tables I needed afterward, but it occured to me that possibly the 11.7 update script had bombed because of those issues. Maybe the update script isn't as bulletproof as the install script is.

 

[eugenio]

Successful clean install with 11.7 on the first instance.

FWIW, the installer complained about tables in my database with non-allowable characters in field names and a couple with missing primary keys and declined to install those tables. I was able to fix all this and install the tables I needed afterward, but it occured to me that possibly the 11.7 update script had bombed because of those issues. Maybe the update script isn't as bulletproof as the install script is.

Hi, no, I don't think this can be related to the upgrade issue.

 

[dh]

OK, I tried "new" upgrade method on the next instance I need to update, and again up2.php hung, and I got the javascript error box again. This time I was alert to the console, and here is the error:

Failed to load resource: the server [installation directory]/up2.php?step=4 responded with a status of 500 (Internal Server Error)

Eugenio, does this help diagnose? up2.php is definitely in the directory, with permissions 644.

 

[eugenio]

Hello,
no, unfortunately "internal server error" is a generic error message that doesn't help; you should check your web server error logs to see if there are details.

Best,

 

[eugenio]

Hello everybody,
a customer reported a specific upgrade problem, causing a "function not defined" error, when upgrading a 9.x version to 11.7 using the up/up2 procedure.
I debugged the error and I confirm I have found an issue that is triggered when upgrading a version <= 11.4 to V 11.7.
So, for example, upgrading 11.5 to 11.7 or upgrading 9.0 to 11.6 does not trigger this issue. This is also compatible with the behaviour that @dh reported.

I have already fixed the bug and I've silently upgraded the current V 11.7 online.

I don't know if your problems were due to the same issue (you didn't reported the same error message) but it could be.
If you want to download the patched version, write to the support email or send a message from https://dadabik.com/index.php?function=show_contacts and you will receive instructions.



best,

 

[dh]

Hello everybody,
a customer reported a specific upgrade problem, causing a "function not defined" error, when upgrading a 9.x version to 11.7 using the up/up2 procedure.
I debugged the error and I confirm I have found an issue that is triggered when upgrading a version <= 11.4 to V 11.7.
So, for example, upgrading 11.5 to 11.7 or upgrading 9.0 to 11.6 does not trigger this issue. This is also compatible with the behaviour that @dh reported.

I have already fixed the bug and I've silently upgraded the current V 11.7 online.

I don't know if your problems were due to the same issue (you didn't reported the same error message) but it could be.
If you want to download the patched version, write to the support email or send a message from https://dadabik.com/index.php?function=show_contacts and you will receive instructions.



best,

Thanks! I have sent the request via the site form.

 

[dh]

Thanks! I have sent the request via the site form.

Thanks for the upgrade code. One more question. Is there any reason to apply the patched version to two instances I already did a fresh re-install on? These instances seem to be working fine and I'd be inclined to leave well enough alone, assuming that the next dot release will upgrade properly by the new method regardless of whether original or patched 11.7 is installed.

 

[eugenio]

No, there is no reason for doing it, the bug was in the file up2.php, which is only used for upgrading.
As I wrote in the email, this patched version also fixes this minor bug:
"For certain versions of MySQL, integer fields types are not recognized in the admin>data page if you set Data types to "simple" (because MySQL returns int(11) instead of int) and therefore you got the blank option selected for the field type when you opened the data page. Fixed."
so the only reason would be having also this bug fixed.

Best,