Local database (serveless) not modifiable with update

Asked

Viewed 182 times

1

Setting:

I’m developing a small app WinForm in C# to distribute to sellers to assemble their quotes more quickly and would like to store simple information such as budget issued and registered customers.

Well, until today I developed only working with SQL Server, but in this project I would like to install, along with the distribution of the application, a local database in each client that is not affected if the application is updated.

I searched some options of "small db", such as SQLite, but as I understand it, the file with the logs is distributed along with the application and my concern is in not losing the data already saved on each PC.

Is there any standard way to handle this?

My question is at the time of application update: if the database is distributed along with the application, soon it will be replaced in a possible update, correct (or not?). It’s this problem that I don’t know how to handle and I’d like to get around.

How to work using and storing records in local databases for each client, without there being substituição of these Bank in an app update?

  • 1

    What you mean by "don’t lose the data already saved on each PC"?

  • I mean that in my head, when updating an application that uses local data, the files where records are stored will also be overwritten, right? Or not? Such data loss I want to avoid.

2 answers

3


Just leaving my 2 cents, there is portable SQL Server mode called Localdb. You do not need to install the entire SQL Server on the user’s machine: only the client adapter and the MDF file representing the database.

Also, if by some chance you choose the Entity Framework as framework abstraction of your database, you can make the data updates using the mechanism of Migrations. The database is not replaced: it is automatically updated according to the variations produced in your code when developing the application.

2

When you leave the data in the customer, you will always risk losing it, there is nothing that can be done. The file can be accidentally deleted by the user or viruses, equipment malfunction, etc. In fact it is the same risk of the server, the difference is that this usually has more access restriction, is not manipulated by laymen (in practice it is usually :) ) and there are good strategies of backup (not always :) ).

What can be done is a local database synchronization strategy with a copy on the server. You can even use Sqlite instances on the server to store each vendor’s database.

The client will identify each time he has access to the server and start the synchronization. It will also identify whether the server may be more up-to-date and synchronize in reverse. This may also be useful if the seller uses more than one device.

The server will have a service that will communicate with the client and record the updates in the server copy. Or send the updated data to the client when the server is more current.

The details of how to do this, strategies to detect outdated more easily would not fit here. Eventually you can make a copy of the whole file all the time, just based on his schedule. Not the most efficient and robust, but works in almost all cases.

Of course there are always simpler strategies like making more local copies, forcing the user to do something manually, etc.

About the app update

If it is update, it should not be copied. Simple like this.

And if an overlap happens by accident, only the strategy described above will solve.

If the database structure has changed, there has to be a routine that makes the change. The ALTER TABLE The Sqlite is weak. You have to create a new table, copy the existing data in the old table to the new one, treating the differences from the old structure to the new one. Then delete the old and rename the new.

  • Thanks for the @bigown contribution, but actually, on that sync and backup part, I already have a strategy in mind to deal with it. My question is focused on the question of the moment of application update: if the database is distributed along with the application, soon it will be replaced in a possible update, correct (or not?). It’s this problem that I don’t know how to handle and I’d like to get around.

  • Nobody is understanding what you want. You have to explain better. For me, the loss can only occur in this situation that I described. If there can be loss at another time, you have to say what you are doing and why there may be loss. Maybe you should just stop doing what can cause the loss.

  • Fair. It’s actually a purely theoretical and conceptual problem. It’s not that I esteja doing something wrong, I just não sei how to do it. Punctuation: how to work with a local database for each client. Understand?

  • I tried to improve, but since your first comment and the issues, you are being almost redundant in the information without putting real clarifications. Phrases like "how I work with a local database for every customer" say nothing about what you need, what your problem is. That is, the question becomes very wide. I answered what happens with what was written. If you need something more specific, you will have to specify.

  • Okay, you’ve helped me on a few points. It’s tricky to ask something when you don’t know what the possibilities are. But thank you.

  • 1

    The possibilities I’ve already posed. If you have a more specific problem, you have to specify. When you put the general question, and there’s no inherent problem with that, you get a generic answer. When you are dealing with the real problem,m you can post a question showing it and asking how to resolve the situation.

  • 1

    The idea of setting up a data sync server is pretty cool. It could even be offered as an additional service along with the product. + 1.

Show 2 more comments

Browser other questions tagged

You are not signed in. Login or sign up in order to post.