After upgrade to version 20.8.99 on Ubuntu Manager does not open

I am running Ubuntu 20.04. After upgraded to Manager 20.8.99 the application does not open. A screenshot of the error message attached. If I run the AppImage file again, it does open.

@Danie_Crowther, please do not post links to images. Upload them directly to the forum so members can see them without worrying about being directed to malicious sites. I edited your post to display your message.

I do not know why your operating system threw this error. I can only note that it was not generated by Manager.

It looks like you are updating from 19.7.34 to 20.8.99.
There have been so many updates and changes in the last 12 months+ that it won’t update. I think you’ll find that @lubos will have to look at this for you.

Yeah doesn’t look good. BUT it’s recoverable :slight_smile:

There are a number of issues there, the least of which is the old Manager version. On the surface of it, you’re trying to open a newer version of the database in an older version of the app. So one of a number of things have happened, and my guess is you used the new version to open your current database, and maybe you decided to go back to the old version? However, when you opened it in the new version, the database was converted to the newer current schema and now the older Manager version can’t open it.

I have asked for a database schema version tool but it’s not going to happen. If you’re on ubuntu and running the desktop version and want to revert back to an old version of the app you are going to have to:

  1. remove everything under ~/.local/share/Manager (ensuring you have backups first)*
  2. reinstall/deploy manager and open it (it should open now)
  3. import your database backup.

lubos has promised that one day we will be able to open multiple versions of manager at the same time**, currently that is not possible.

* TBH you only need to delete certain files, and it depends
** I’m not sure whether he means to have them actually running at the same time (I doubt that, but possible), I think it means you could open one version of manager and close it and open another. Either way, it’s not yet implemented.

But (after all that), it’s also possible you meant to open it using the newer version and you accidentally used the old version of manager from the search tool/desktop/however you open apps. If that’s the case, just make sure you’re using the correct AppImage. :slight_smile:

@d3mad I believe that if required the program updates the database during installation. That error looks like the old database is so far behind the version trying to install and can’t find certain id’s etc that would have progressively updated/changed over the 12+ months.
I have seen this issue previously mentioned on the forums and @lubos has been able to help out.

There is some speculation in this thread. I offer two observations (one reiterates something I wrote earlier):

  • The error message is not from Manager. I am not sure there is any reason to believe the prior Manager version was 19.7.34. Someone with experience in Ubuntu error messages needs to contribute their knowledge on what exactly this one means.
  • Even if the prior Manager version was 19.7.34, that is well within bounds for handling by the update script(s). If the version were from 2014 or something, the time gap might be an issue.

Yeah I’m pretty sure I’ve nailed it.

I’m using OSX so it’s a little “fun” trying to do this, but achievable:

open -a /Applications/ --args -path ~/db20896/

This attempts to open manager version 20517 with a current-ish database (20896). This produces the error result below:

Screen Shot 2020-09-11 at 12.25.07 am

The oldest manager I have on this now is 19.12.12, using a modern database (same one) I will get the following error:

Screen Shot 2020-09-11 at 12.38.05 am

As can be seen I am trying to load a database that is using schema 242 (which is from version 20.8.96).

Manager 20.5.17 is expecting schema 234 (but got 242)
Manager 19.12.12 is expecting 227 but got 242
Manager 19.7.34 is expecting schema 220, but… 242 (current)

@VACUUMDOG nothing happens when you “install” manager, the conversion will happen the first time it is run and the conversion is attempted.

@tut the error IS a manager error, it’s the error generated when the application first loads and attempts to convert an old database. refer error code:
Manager.Upgrade+UpgradeException: Schema 242 > 234
in the first screenshot. Hopefully errors will remain at least this clear in the future. He has made it clear enough so that if you know what you are doing, you can see it, but he doesn’t advertise it at all.

Without lubos’ assistance I have spent MANY WEEKS over the last few months trying to piece together stuff like this. It’s a shame, I would very much appreciate schemas vs applications versions, but he doesn’t want users to manipulate the database in that way. He would prefer everyone to use the latest version only (and I do get that, but there are times when we need it)

You could call it “speculation”, but I prefer to call it “an educated guess supported by empirical evidence”. :slight_smile:

I didn’t try it, but I do believe a database from 19.7.34 would be updated without a problem with the current version, but as demonstrated, that’s not what’s happening here.

@Danie_Crowther, just open the database in the current version. Or if you want to use the old version, you will need to use the last backup you created with it. (This is where I am speculating:) I think you likely wanted the newer database but used the old application by mistake. But that’s just a hunch.

My statement referred to the fact that the error message was generated by the operating system, not by Manager. The root cause may be something that happened during a process involving Manager, but Manager did not produce the message. That is all I was saying.

Manager’s error messages are distinctive and recognizable as such. The developer always considers those to be indicative of a bug. Operating system error messages may or may not indicate bugs.

Nah, that’s just linux, it doesn’t always include the icon, especially ubuntu. Most of my apps unless they include a .desktop file and have it installed correctly (and manager doesn’t have one at all), they will have no icon displayed. Don’t be put off by the exclamation mark.

You can see the general form of the error is purely C#/mono in manager’s usual output. A linux/ubuntu crash report is totally different.

Well I’m sorry I posted a reply…

I was referring to error messages like this:

Screen Shot 2020-09-10 at 9.51.25 AM

No icon, clearly labeled as Internal Error, version number displayed, distinctive coloration. That is nothing like what the original poster put up.

@VACUUMDOG please do post replies, it’s the only way we learn is by helping each other. I wasn’t having a go at you.

@tut, you’ve lost me. That error has nothing to do with anything that’s previously appeared in this thread. Notwithstanding, although it may say “Internal Error”, you are aware that it is distinctly generated by Manager? You can see it all down the left side of the dialog, the error is from the ManagerServer (in your case), in the OP and my images, we have both used the Desktop Versions.

The error you are illustrating is in fact generated by the manager runtime as that error that appears on the sales invoice by totals customer list report and is as a result of a programming error/bug where an object has a null reference (is not set) and has been called upon by the underlying report. That’s a manager error, thrown by manager. But still, I fail to see any reference anywhere about the internal error message you posted, when did anyone mention that/those? That’s way off topic.

Back to what the OP and I posted, error messages from the desktop version where database versions are being opened by older versions of the app:

About the OP’s image:

you replied:

I was demonstrating his error message IS an error message thrown by Manager, and it’s because of the database conversion. Have a look at his error message and mine posted from OSX (they are slightly different, but I’m sure you can see it if you read the underlying messages).

1 Like

I know that. I posted it as an example (because you cannot generate the error you are recreating in Manager’s format). I clearly wrote “messages like this.” I did not write “this error message” or anything similar. Pay no attention to what that particular message said. It just illustrates the recognizable Manager format and coloration. They are structured to provide the developer specific debugging information.

You are beating a dead horse. The original error message and your examples were all generated by operating systems. They are in the format of the operating systems, regardless of their root cause. I have already stipulated they may have been caused by things related to Manager, possibly even by processes controlled by Manager’s application, installer, or conversion script. But they were not generated by Manager. Both you and the original poster did things with older and newer versions of databases and the application that triggered the operating system error messages. Error messages created by Manager, regardless of operating system, look like the one I showed as an example. Those are the ones the developer considers to always be bugs.

Your messages could also indicate bugs. But that does not mean they were generated by Manager.