I have an AIR application and I would like use SQLite instead of an XML file to populate the database. I've seen people create the database on the fly and import the data when the application first launches. But also people are using existing databases. What approach do you use to prepopulate the database? Is there a tool to enter basic initial data (~200 records and 2 tables) or should I create the database and contents manually when the app is first installed.
More context
This is a mobile AIR application using Flex 4.6.
There are numerous tools to manage SQLite databases, such as Lita which is an open source AIR application.
If there is no need to revert the database back to its original content, then it could simply be packaged in the app with your populated content.
If restoring the database to its original populated data is required, you could keep a copy of the original database and stage it to the active database in use, thereby replacing the database.
Depending on data and parity of your app to the database model, it wouldn't be unreasonable to populate your database via programmatic implementation in code executed at first launch. There is overhead both in initial launch of your app and perhaps mostly in code you must generate and maintain to create the database.
Typically, I would only follow this pattern if I have a default model with serialization of that model. As in, if I had already built a commit of preferences style data from my models to persist in a database.
Related
I wanted to fill a SQLite database with some initial data required for my app so I made a flutter app and used it to fill generate that database with the SQFLite package and then took it and put it in the assets folder of the app it will be used in, but when I query the initial data table it tells me that the table doesn't exist although the file size says that there is data in there and I used an online SQLite viewer website and the table with the data were there, So what to do?!.
A quick way to dump an existing database is schema is:
print(await db.query("sqlite_master"));
Without code, hard to say whether you correctly open the database from your assets.
You should also check that the existing database has indeed the data using some 3rd party tool (sqlite3, sqlite browser).
There are thousands of on-premises servers who are running all different versions of a piece of software including a specific version of a database (all at different companies)
Out of a central development department regularly new versions or pushed of the software with database updates (new tables, new views, new foreign keys, new inserts for enums or specific tables, new stored procedures, etc)
These changes come from many different development branches all bringing in their own bits of sql code that affects the schema
Updating client is handled via a .sql file which verifies the local installed latest database schema release version and the sql code that is annotated as later is ran to update a specific physical machine to a later version (automatically without user involvement)
An idea is now to instead use the EF SSDL description of the specific assembly distributed to bring a database schema (sql server) to the latest version. It would need to compare every table, column, constraint, etc to check if they are equal and if not update them taking into account dependencies.
Question: is there an existing package which would do this? So that e.g. when starting an application it would check the existing physical database versus the SSDL and brings them in sync automagically? It would have to skip database objects that are not in the SSDL since a database could contain tables or views which were added by a specific customer and is not part of the database objects needed by the application or is the current approach the best way to go? (in itself this is another approach than e.g. redgate with comparing the physical database) ?
(the only related question i found here is Purpose of edmgen validation? Comparing SSDL and database schemas?)
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.
I am making a contact book application in Qt.
I want my application to automatically create an QSQLITE database when it first runs and then access this database in future?
Is there a way to do this?
Ya you can create sqlite database at its first run and can make it progressive. Just do it in the constructor of your App and check for the existence of db before cerating it, else don't create. You can access database in subsequent runs of your same App or different App.
Use db.setDatabaseName("databasename.db"); instead of db.setDatabaseName(":memory:");, now your database will be persistent.
I want to provide iCloud support for my wrapper around sqlite. Is not using coredata.
I wonder how enable iCloud for it. The database content is changed all the time (is for invoicing). Also, if is possible to have some kind of versioning will be great.
Exist any sample I can use to do this?
The short answer is no, you would need to use Core Data as you suspected. Apple has stated that sqlite is unsupported.
Edit: Check out the section on iCloud that's now in the iOS Application Programming Guide under Using iCloud in Conjunction with Databases
Using iCloud with a SQLite database is possible only if your app uses
Core Data to manage that database. Accessing live database files in
iCloud using the SQLite interfaces is not supported and will likely
corrupt your database. However, you can create a Core Data store based
on SQLite as long as you follow a few extra steps when setting up your
Core Data structures. You can also continue to use other types of Core
Data stores—that is, stores not based on SQLite—without any special
modifications.
You can't just put the SQLite database in the iCloud container, because it might get corrupted. (As you modify an SQLite DB, temporary files are created and renamed, so if the sync process starts copying those files, you'll get a corrupt database.)
If you don't want to move to Core Data, you can do what Core Data does: store your database in your document folder, and store a transaction log in the iCould container. Every time you change the database, you add those changes to a log file, so you can play them back and make equivalent changes on other devices.
This gets pretty complicated: aside from getting the log/reply logic right, you'll want to coalesce redundant changes and periodically collapse the log into a complete copy of the database.
You might have an easier time developing a solution if you can exploit knowledge of your application (Core Data has to solve the problem in the general case). For example, you could save invoices as separate files in the cloud container (text, Property List, XML, JSON, whatever), writing them out as the database changes and only importing ones if the system tells you they were created or changed.
In summary, your choice is either to migrate to Core Data or write a sync solution yourself. Which one is best depends on the particulars of your application.