Manager does not start after recent update on Ubuntu

I’ve just updated and run into this issue
[15:46:53] An exception was thrown by the type initializer for SQLite.SQLiteConnection (TypeInitializationException)
when Manager tries to start.

Manager is server version [16.12.15]

Is your Ubuntu 32-bit or 64-bit?

The reason why I’m asking is because Manager is now using SQLite for data persistence and for Linux, only 64-bit version of SQLite is included.

Hi i have the same problem with my update from Version 16.12.0 to 16.12.15. I downgrade it and it works fine.

? Have you an Idea?

Are you using Ubuntu, if so, is it 32 bit or 64 bit. If 32 bit, then re-read Lubos comment:

"Manager is now using SQLite . . . . for Linux, only the 64-bit version of SQLite is included (in Manager).

No i using Manjaro Linux, 64 bit.
sqlite 3.15.1-2 is installed in my Packages.

Which Version is in Manager included? Why it works wtth the Manager Version from last week?

My linux kernel is
3.13.0-86-generic #131-Ubuntu SMP Thu May 12 23:32:41 UTC 2016 i686 i686 i686 GNU/Linux

So it’s 32-bit. What can I do to fix this issue?

For my docker image I use mono:4-6 image, and build produces the same bug.


can I have 16.12.0 release just to get up and running ASAP?

Unfortunately this issue becomes more critical for me :frowning:

Here is the last version without SQLite. It’s v16.12.1

ManagerServer.tar.gz (7.8 MB)

It works again, thanks!

Is there any chance to resolve 32-bit SQLite incompatibility?

I’m looking into it. I definitely think Manager should be supported on 32-bit Linux too.

Im having the same SQLite.SQLiteConnection exception issue on the desktop version (v16.12.18) on a 64bits linux install (archlinux):

That is my Problem too. :slight_smile:

Not sure why there is an issue on 64-bit Linux. I will need to reproduce it.

Here are the last versions of desktop edition for Linux without SQLite which should work until the problem is fixed in the latest version.

Manager.deb (7.1 MB)

Manager.rpm (7.5 MB)

I have 16.12.11 on Linux Mint 17.3 64bit and it is working fine.
Is it possibly the out of date mono problem still?

I have SQLite3 version 3.8.2 already installed. I wonder if any of the people having this problem can try installing SQLite3 form their respective package managers and see if that helps?

Just in case this is the mono version I’m using:

Mono JIT compiler version 4.6.1 (Stable Mon Oct 3 07:51:42 UTC 2016)

Also the SQLite3 package is installed but it shouldn’t be needed because lubos is using a .Net library (maybe this one GitHub - praeclarum/sqlite-net: Simple, powerful, cross-platform SQLite client and ORM for .NET) to create and access sqlite databases (which he is shipping with Manager.), unless that .net library is doing system calls to the sqlite3 executable, which I doubt (but its developers should know).

In any case the sqlite3 binary version is 3.15.2 2016-11-28 19:13:37

Also I’m using this packaging script for achlinux which I’m maintaining now: AUR (en) - manager-accounting

Some interesting reports with other developers having the same issue with the sql-net library Issues · praeclarum/sqlite-net · GitHub

You are totally right. As far as I know, the library would always load locally deployed so it doesn’t matter whether SQLite is installed globally.

Regarding 32-bit issue on Linux, I have asked about this Eric Sink who has developed underlying library calling into SQLite Linux 32-bit support · Issue #113 · ericsink/SQLitePCL.raw · GitHub

Now that you mention I saw that some one mentioned as missing when deploying on android, but since I wasn’t sure if this was android specific I didn’t said anything. So basically sqlite-net makes native calls to an sqlite3 library ( which I noticed is missing from which is the source file im using to build the ArchLinux manager-accounting package, thats why it was throwing the connection exceptionm, but also the .so file is missing from

So adding to and Manager.rpm should fix the issue :), at least for those that are running a 64bit linux and using the zip or rpm files instead of the deb. It seems like the packaging script used to build all those packages isn’t including Hope this discovery helps a bit.

Now I can see what is wrong. It seems putting into Debian package seems more complicated than I originally thought. I’ve embedded this file into one of DLLs. When Manager is launched the first time on Linux, it will check whether it’s running in 32-bit or 64-bit mode and will copy the correct into program folder. This should also solve the issue when Manager didn’t run on 32-bit systems at all.

So try again and see if it works.

Yes! Now it works, but required me to delete all old files, overwriting is not the option in that case.