Your comments

Nikolaj, would it be possible for you to share a little more detail and possibly some code around how you're doing this? I'm very interested. We can leverage Azure SQL Databases, Azure Blob Storage, and Azure WebApps to accomplish the same but a starting point would be fantastic!

Alex, no worries. Yes there have been reports of successfully switching to MSSQL but as you and Sean noted, these are not supported configurations. The general response from support for any DB issue is to wipe and rebuild. I've been troubleshooting a memory leak issue and the FIRST suggestion was to dump the entire DB and start from scratch. Um.... how is that a solution, never mind the first suggestion.

I'm honestly in favor of any database technology that will get us the features we're looking for. I'm an Azure shop so being able to use Azure based SQL databases whether they be MSSQL or MySQL would be a game changer but I'm pretty much open to anything. As you noted, I believe most if not all open source database solutions are not VSS friendly, however MySQL also gives us options in the way of database HA such that we can take a database node down for backup every hour.

I'm curious to see if we can get some traction going on this. It's clearly something the community wants/needs and aside from the labor it will take to rewrite the necessary code, I see no drawbacks to a change in DB technology especially if the application defaults to SQLite and gives us the option of using a more resilient database engine.

Alex, I had a semi-decent conversation with Sean White over at ConnectWise who is a senior Product Manager for ConnectWise Control but unfortunately I don't think it went anywhere. I'm mainly after high availability which is near impossible with SQLite. There are an abundance of code changes required for HA to be possible due to the fact that the DB is loaded into RAM and thus can't read updated information written to the DB by another node, but a standby node referencing the same DB could be started upon failure of the primary node and theoretically would work fine. I'm exploring this option independently with the current SQLite database but having a central database that both nodes could talk to would be ideal so we don't need to store the SQLite DB on shared/network storage, or implement some type of database syncing.

With the reporting, I basically gave up trying to run queries against the database file. The few times I've done this, it resulted in crashing of the application and in two cases, database loss.

What sort of retention do you have for logs and extended logging? We require at a minimum 90 days of extended auditing retention and would like to store more than that. This tends to bloat the database, and is where a more resilient database engine would shine. Also, how are you handling uptime? With each instance only being able to run on a single server with read/write access to the SQLite database file, what happens when that server goes down, or the application has issues, you can't simply fail over to another node that points to the same data.

There has been a lot of talk here about wanting a database such as MySQL or MSSQL as opposed to SQLite for performance, and reporting which are valid points but what about redundancy or HA. We have been plagued by application level issues lately which ultimately caused us to lose our 5GB database. Had this information been stored in MySQL or MSSQL, not only could the data have been preserved, but we could even have had a secondary server so we could continue supporting our clients while we fixed the application issues on the main server. If Control is to be a proper remote support application, we need to be able to ensure uptime regardless of whether the issue is server, application, or network related. This is simply impossible with the current database design. ConnectWise, please implement this.