I assume nothing has changed but maybe it has and I can’t find the solution.
Currently, I send the database as an embedded binary resource at deployment. On boot up, I have to load the resource to memory and then save it to the SD card. Once it is on the SD card I use the standard SQLiteDatabase() function to get it from the SD card. It seems like a lot of extra steps to move the same bytes around. Does anyone have any other way to eliminate the need for the SD card?
Why not just script your database and content to sql statements and embed these in a class in your project? hen create a memory database at runtime with this.
i used differently - created DB with SqlLite tools on Windows and put on SD CARD e left there as part of it, and deployed exe to find if exist use it - if not than create it …
but yet not tried to get from web via ftp … and store into sd … to be used later on TinyCLR
and not tried to use it on flash memory … (since i use just for less 1000 recrds data)
Since the language DB is critical to the operation I am hoping to keep it off the SD card in case the SD card gets corrupted. I don’t see any way for TinyCLR to format an SD card or recover it from corruption.
I also use the SqlLite tools on the desktop to create and fill the database. By having it as a resource it gets deployed easily when I do infield updates.
SQLite seems too heavy to me. Another way to load language resource is first serialize language dictionary to json and embed the json as resource. At the boot time microcontroller load the resources and deserialize them in the memory, you can retrive your language from deserialized object all you want.
It sounds like if I am to use SQLite in this scenario without the SD card or USB stick, one of three options would need to be supported.
Be able to directly load an embedded resource as an SQLite database.
Support TFS for SQLite instead of just FAT file system.
Support FAT file system on unused QSPI flash.
I guess I am not holding my breath that any of the above could happen. I know there are far more pressing issues for the TinyCLR team to be working on.
question is how much / how long you need data to have on DB why not send collected data after certain time on server via FTP ose via WEB API - and kept minimalistic data that you need onto embed system
These devices are generally not connected to any internet connection. They live out in rock quarries and mines and need to have an operational life of about 10yrs or more.
Only about 10% will ever get connected to the internet. If we provide a software update to a device it will be through USB stick.
I do have some FRAM on board already for the fast-changing data that has to be saved every second or more. It is expensive but I could add more, however, SQLite can only load an existing database from a FAT file system. So far TinyCLR only supports FAT on SD or USB.
The primary issue with using FAT in the field is that if it gets corrupted there is no way in TinyCLR to recover it. There is no Format option to re-format an SD or USB drive in the event that it gets corrupted. (At least I don’t find a Format option.)
So while my database lives as a resource in memory, at boot I have to write it to a FAT file system in order to load it into SQLite. If at some point during the life of the device, the FAT files system gets corrupted I can no longer load the database. So while SQLite is a nice feature it shouldn’t be used for anything super critical to the device’s operation.
I haven’t made the change yet but I will probably include the language database as a CSV text file as a resource. At boot up, I will parse through it and load the currently selected language strings into a Hashtable.