Redmine

What are you doing? Are you restoring a Redmine instance or are you upgrading one?
If you are restoring, then don't simultaneously upgrade it to a newer version. Complete the restore first and then you could start the upgrade procedure. If you are upgrading, then follow all the given steps in RedmineUpgrade.

Though, given the provided information I'd say you miss the 4.1.x DB-migrations. Following step four in the referenced wiki page should solve the error you are having.

Thanks Mischa I did that of course. Step 4 is required regardless if you are having a fresh install or an upgrade, otherwise mysql database would not be linked to v4.1.1.

In fact I can successfully login to the redmine instance on the new version and can see the project list and the overall issue list. That strange error blocks it from showing individual projects (or issues). Everything else is available to me.

It does not seem right (intuitively to me at least) that you cannot restore a database from a server running an older redmine version directly to a newer brand-new installation on a different machine. I have a complex virtualisation juggle with it, so it's critical for me to have redmine installed on a fresh system and have the db backup restored to it.

The database itself is not ported on a particular redmine/gem version set, so this should not be an issue. Or is it?

Hi A Fora,
Running

 bundle exec rake db:migrate RAILS_ENV=production 

should fix your problem.

Thanks Kumar, I'm already running it (line 2 below) as a part of my rake protocol:

bundle exec rake generate_secret_token
bundle exec rake db:migrate RAILS_ENV=production
bundle exec rake redmine:plugins:migrate RAILS_ENV=production
bundle exec rake redmine:load_default_data RAILS_ENV=production REDMINE_LANG=en
bundle exec rake tmp:cache:clear RAILS_ENV=production

As I pointed out - I can login to the database in v4.1.1 and see some of its sections, I suspect the db:migrate command may not be the issue.

Really I am a new user for Redmine. I had an experience like this I tried to turn back to an old version. Somehow I don't know but db is being affected ffrom the schemas running background. I am using Bitnami Redmine Plus Agile. May help.

https://community.bitnami.com/t/database-transfer-from-another-computer/78269?source_topic_id=80417

I can access the new database, the 500 error appears when browsing individual Issues inside it. So this my not relate to the problem you solved.

Also, I do not have any plugins with a direct redmine install (not a bitnami stack like in your case).

Sadly the issue is still unresolved.

In cases like this I can only recommend to either find someone who is sufficiently skilled to manage your Redmine deployment on-premise or decide to outsource both the hosting and management to a hosted Redmine provider.
That being said, I'll try to help you anyway.

A Fora wrote:

The database itself is not ported on a particular redmine/gem version set, so this should not be an issue. Or is it?

Well. You are clearly having an issue with it, don't you? And that's because the Redmine database schema changed between versions 4.0.x and 4.1.x. And since your DB is not properly migrated you are getting the given error.
You can see this for yourself by looking at the schema file in /db/schema.rb. For the trackers table on Redmine 4.1.x for example, it should look like following:

  create_table "trackers", id: :integer, options: "ENGINE=InnoDB DEFAULT CHARSET=utf8mb4", force: :cascade do |t|
    t.string "name", limit: 30, default: "", null: false
    t.string "description" 
    t.boolean "is_in_chlog", default: false, null: false
    t.integer "position" 
    t.boolean "is_in_roadmap", default: true, null: false
    t.integer "fields_bits", default: 0
    t.integer "default_status_id" 
  end

I'm pretty certain you are missing the description field here. Like also stated by kumar abhinav (and Go MAEDA in the issue you opened), you still need to properly migrate you database to the current 4.1.x state.

A Fora wrote:

Thanks Kumar, I'm already running it (line 2 below) as a part of my rake protocol:

There is no such thing as a rake protocol.

A Fora wrote:

bundle exec rake generate_secret_token
bundle exec rake db:migrate RAILS_ENV=production
bundle exec rake redmine:plugins:migrate RAILS_ENV=production
bundle exec rake redmine:load_default_data RAILS_ENV=production REDMINE_LANG=en
bundle exec rake tmp:cache:clear RAILS_ENV=production

These are the steps for a fresh install of Redmine mixed together with upgrade steps, not the steps for a restoration or an upgrade. Again, don't mix-up these different processes. E.g. you don't want to load the default data into your database if you are restoring or upgrading.

A Fora wrote:

[...] I suspect the db:migrate command may not be the issue.

I'm convinced your suspicion is not right.

What output do you get from the DB-migration command?

Hi
I think I couldn't express my case, in my case, first the database name was different cominng from using different versions. I solved this issue by the help of PhpMyAdmin page as I explained in the previous post. For the plugins and the 500 error, I found that the backing up method is very important however it is written in the forums and bitnami pages as same.

https://docs.bitnami.com/installer/apps/redmine/administration/backup-restore-mysql-mariadb/

When I use th following command I have the same problem.

mysqldump -A -u root -p > backup.sql

But when I use the following nothing happened and I could start all plugins

mysqldump -u root -p bitnami_app > backup.sql

Wish you luck

Mischa The Evil wrote:

Well. You are clearly having an issue with it, don't you? And that's because the Redmine database schema changed between versions 4.0.x and 4.1.x. And since your DB is not properly migrated you are getting the given error.

Thanks Mischa, it makes sense.

Also out of curiosity, does it mean (if there is a need in the future) that downgrading the version will be impossible? Or it will simply result in a loss of some data if the schema was less descriptive in prior versions?

A Fora wrote:

Also out of curiosity, does it mean (if there is a need in the future) that downgrading the version will be impossible? Or it will simply result in a loss of some data if the schema was less descriptive in prior versions?

Downgrading (i.e. reversing a schema migration) is possible (albeit not without dropping data, obviously [think about reversing the creation of a new table]) unless one or more migrations are irreversible.
See the Rails guide on Active Record Migrations for more information.