I was just looking for some guidance with my app design. I'm going to have a local sqllite database pre populated with about 1000 records.
These records will need to be read frequently within the app to update the UI.
The records will need to be updated from within the app.
Is a local mysql database the best way to do this or should I be storing all this info in a massive lua table? The database has 2 tables one with 2 columns and one with 10 columns.
I don't want the data to be accessible from outside the app as some of the data is going to be paid for content.
How would I go about releasing updates in the future? If I upgrade my app to version 2 and add new records to the database... how would I go about keeping the users existing data in the database and just adding the updated stuff?
Hope someone can point me in the right direction!
Many Thanks,
Krivvenz.
I think this is fairly simple question. If you need to use data after closing and opening the app you will need sqlite. If the data is created and lost after the app usage, then a table will do. However, the sqlite has also the advantage of querying, deleting and so many other functions without loops etc that you may need to do in tables manually.
You can also append further data during app update. The Sqlite file you create is saved to document directory. That is not deleted if you only update. Simply write a code in your update that reads the existing database and appends the new data. Or create a new file for sqlite and use the old one as backup.
Related
It's probably a simple and common thing but I just can't find any help to do this in Ionic 5 app.
I have an app with local SQLite db. During the development when I update the table in the local db, I need to delete app/clean storage on the device for the update to be available. Is there a way to apply new changes on the existing db without losing data (without creating the whole db)?
same once app is released, with new updates, how do I make sure that new db changes are applied without re-creating the database?
A simple way I can think of is to put new changes in dbService constructor and check every time and apply change if need to. But this doesn't feel right to me.
Thanks
I have a .NET 6 application that writes logs out to a SQLite file each time a cycle is completed. I'm using EF Core.
The application sits on a Raspberry Pi with limited resource, so I want to keep the live database small as when it gets large the system slows down. So I want to archive the logs to only keep the last 50 or so logs in the live database.
I am hoping to create a method that will will create a new SQLite database file and then copy the last oldest record over when a new log is created. I'd also want to limit how big the archive file is, maybe split out to create a new one once it reaches a certain size on disk.
I've had a look around and can't find any best practices anything documented. Could someone give me a steer to the best way to achieve this or similar.
I solved my issue by putting EFCore aside and instead using the sqlite-net-pcl nuget package from SQLite-net.
This allowed me to separate the creation of my archive and also apply additional commands not supported in EFCore like vacuum.
I still use EFCore and Linq to query the records to create my archive with and then again to remove those records once the archive is created.
I am creating an app it takes data from the server and storing it in SQLite database but each time I run the app the data gets append in the database. I tried onUpgrade() method to drop table and create a new one, but its not working because db_version is the same. But if I change the version manually then its working... but I want solution so that my version changes each time automatically when I run the app....
OR if there is an another alternative please share it....
You are probably didn't understand what is database Upgrade. In two words you upgrade the version of your database when your DB model changed, not the data!
To clear your database for testing purposes use sqlite DROP TABLE or physically delete the file!
If you upgrade the version of the database each time your app starts - you will lose all the database data each time your app starts, so why do you need the database ?
I had a website, with an sql server database. I decided to create a new version of the site, so I downloaded the database + website onto my local dev PC, and added a whole bunch of stuff to both - in particular, I added lots of new stored procedures, columns and tables to the database, while leaving the existing data for the site in place while doing this.
It is now time to launch the new version. Of course, while working on the new version, the data in the database on the live site has changed - new users have signed up and so on, so I can't just push the dev enviroment database live, as this would lose data.
What is the best way to import all the data from the existing database into the new database configuration? Should I take the existing database, and then add all the columns, procs, tables, indexes and so on in to it, or is there a better way?
You can use SQL Compare or other comparison tools to make the production database look like your dev database. If budget is a concern you can see plenty of alternatives in this blog post.
In SQL Server Management Studio , right click on your local database -> Task -> Generate Scripts, and then you'll be able to select your SP/Functions and then execute these script against the production database
The scenario is this. I have a SQL Server database online that I am demoing an application. During development, I have added extra fields, modified field types, changed keys and added some new tables locally.
What's the best way for me to update the online database with the new structure and not lose the data? The database is a SQL Server 2005 one.
Download a trial of Red Gate SQL Compare, compare your two servers and you are done. If you do this often, it is well worth the $400, or get one of their bundles for a better bang for the buck.
And I do not work for Red Gate, just a happy customer!
Write update scripts to modify your live database structure to the new structure, as well as inserting any data which is required.
You may find it necessary to use temporary tables to do this.
It's probably best if you test this process on a test environment, before running the scripts on the live environment.
Depending on what exactly you've done you may be able to get away with alter statements, though from the sounds of it (removing keys and whatnot) you're doing some heavy lifting that may make that a less-than-ideal solution. You should probably look into creating a maintenance plan or, better yet, a SQL Server Integration Services project in Visual Studio. You should be able to migrate the data in the existing database to a new one using those tools.
This probably isn't of huge help retrospectively, but I always script all structural DB changes to my development database and then using a version number to determine the current version of the DB I can run the required scripts on the live DB, hence bringing it back in line at the same time as the new code is uploaded.
This also works for any content changes, for instance if the change in the underlying structure has an effect on the conent stored you can also write scripts to migrate the data accordingly.
Make a copy of the existing database to copy from.
Make another copy and alter it to your new schema. save DDL for reuse.
Write queries that copy data from #1 to #2. Save the queries for reuse.
Check the results.
Repeat until done.