Are there any MIDP implementation of SQLite db available for use of sqlite db within a MIDlet, rather than using RMS. Of course, there are Floggy and OpenBaseMovil, however they are based on RMS, but are there any implementations that allows to perform operations in an sqlite db file?
There are 2 ways of doing something like that:
take the open source code of SQLite (written in C) and write something similar in JavaME. nobody has done that yet. There is an ongoing effort to write a version of SQLite in C# for windows mobile but you have got to wonder what impact a move to an interpreted language with no control over the performance of file system access will have.
define and implement a JavaME API that accesses the native SQLite via something like JNI. This is usually extremely complicated if you are not the phone manufacturer or one of its very close partners. I suspect Android does that so you could look at its sources in that area but it won't be MIDP-compliant. There are no official JSR for an SQLite-like API yet.
J2ME spec does not define JNI. Being an ISV and trying to write native bindings is out of question. Sun's reference implementation does define something called KNI - but then you have to be an OEM to be able to do that and ship the VM with the phone.
Related
I find that there's very little documentation on how to extract SAP tables into R.
I'm not talking about SAP HANA.
Currently, it's very troublesome that I need to manually extract SAP tables using a GUI interface, export them into tabular format. Then only I can import them using my R script.
The current solution I'm exploring is to have my SAP colleagues to export those SAP tables into SQL database, then I can query the tables from R.
Ideally I want to cut this seemingly unnecessary step of having the SAP tables exported into a database.
For SAP R/3 systems (or what you call ECC), your best bet would be executing remote function calls (i.e. RFC).
Normally these would be supported by open source interfaces for at least the more recent versions (e.g. 4.6 or above).
However, they are fairly scarce and I know only of one such implementation in R - this is the RSAP. You'd also need to download NW RFC SDK, and there may be further requirements based on your OS (e.g. what Visual C++ you'd need for Windows, etc.).
There's also a slightly more widely recognised equivalent in Python, the PyRFC.
On the other hand, you may try Robotic Process Automation (RPA) to interact with GUI in an automated way. One of the options is UiPath but there are others. This way you could configure the automation of table extraction - at the same time you can also call R scripts directly from the RPA.
Overall - to be honest - the solution with extracting tables into a separate database does seem to be the best alternative (compared to what I've described above).
Note: The above presumes that - for any reason, usually security - you cannot access the database underlying ECC directly through ODBC calls - otherwise the instructions for connecting and calling SQL from R are the same as for HANA or similar.
Consider using RODBC. This package allows adding different ODBC sources and use them in R Studio.
Follow this article and don't bug to word "HANA", this approach allows using any database, not only HANA.
I'm having trouble getting a overview of the different SQLite libraries to be used with .Net Core and/or Standard.
It seems there are primarily two:
MS: Microsoft.EntityFrameworkCore.Sqlite
sqlite.org: System.Data.SQLite
Is the MS library completely independent of the sqlite.org's libraries? And if so, which one is recommended to use?
I prefer simplicity....it seems I just need two dll's if using sqlite.org.
There are two main SQLite packages for .NET Core/Standard. They are independent and use separate native binaries.
Microsoft.Data.Sqlite
System.Data.SQLite
The former is provided by Microsoft, the latter by SQLite.org. I prefer the Microsoft one but unless you're looking for specific functionality (SQLite.org's supports encryption, Microsoft's supports fts5, etc) either one will probably work fine. They both implement System.Data.Common and so the APIs are almost identical. SQLite.org's can load arbitrary extensions which Microsoft's cannot (though with the latest release it was looking like SQLite.org's couldn't load fts5 which I know worked with previous releases).
I would recommend using Entity Framework Core or another similar third-party database abstraction package unless you absolutely can't use modelling for some reason (EFCore still lets you run the occasional low level query if you need to). It's quicker to develop, and easier to maintain the code.
Microsoft.EntityFrameworkCore.Sqlite provides support for Sqlite in EFCore, using Microsoft.Data.Sqlite. So you would want to use that in this case. The internet says you can also use System.Data.SQLite but it looks like Microsoft.EntityFrameworkCore.Sqlite still tries to load the underlying native binary from Microsoft.Data.Sqlite for some purpose, though it does appear to use System.Data.SQLite for the actual database operations. Not sure exactly what's going on there.
Microsoft.EntityFrameworkCore.Sqlite is for Entity Framework Core ORM is more complete but heavier.
The System.Data.SQLite.Core can use with Dapper ORM SQLite and Dapper but I use the Microsoft.Data.Sqlite.Core with SQLitePCLRaw.bundle_e_sqlite3 and Dapper ORM, I think I had problems with System.Data.SQLite.Core.
Use without is hard and I not recommend.
I need to use an embedded database in my java application that will be run in a Linux device. The application uses Hibernate and derby database. This is not a Android application.
Due to slow performance of the database, we are looking for a better embedded database framework.
Looking at all the options, H2 seems to be better than SQLite as there is no cross-compilation involved and no JNI interface to build.
So, why isn't there a more usage of H2. Are there any drawbacks or issues that I am not aware of.
The SQLite library is implemented in C, so it indeed needs (cross-)compilation and a JNI interface.
However, SQLite is so widely used that it is likely that the SQLite interface already exists (as part of your language's runtime, or as a JDBC driver), and that using it is simpler than explicitly adding H2 to your project. (This might not actually be true in your specific environment.)
If you're looking to speed up your application, you have to measure yourself.
I recently switched from H2 to SQLite because of database corruptions in the H2 mv store.
If the application is not shutdown properly, or in case of unexpected reboots, the H2 database stored on a file using the MV store (the default) can get corrupt, and you can't restore data.
SQLite is much more robust to corruption.
Speed wise H2 was much faster in my case. With SQLite transactions are particularly costly, so you should prefer doing bulk operations within transactions or via batches.
As for cross compilation, you can use the jdbc driver from xerial which ships with all the native binaries precompile : https://github.com/xerial/sqlite-jdbc
I am exploring Zumero for a new project and attempting to understand which SQLite it works with. Mono.data.sqlite, System.data.sqlite, Sqlite-net, or Sqlite-net Extensions. I prefer to use the Extensions version however I suspect that it will not work with it or the Sqlite-net because I would be unable to define the tables using the modified Zumero syntax.
I do need to be able to sync multiple smart devices with themselves and with desktop. Any ideas would be helpful.
The current version of our Xamarin component supports (and includes) System.Data.SQLite.
As you suspect, the ORM-ish features of Sqlite-net (and its variants) are not yet supported because Zumero tables need to be created a bit differently than regular tables. We do plan to implement this functionality, but I cannot yet promise a specific availability date.
I'm working on an embedded project that has no file system, and our kludge of a database has ballooned in functionality. It's now so inefficient, we can't stand it any longer.
I'm trying to figure out if there's built-in support for a flat file system in SQLite. I've dug around http://sqlite.org for a while now, but haven't found anything specifically covering it. Has anyone found a supported implementation written in C? It seems like such a straightforward request, but I can't find anything written about it.
We have plenty of memory available. In a perfect world, I'd like to just set aside a large portion of it, pass the FS a pointer, then let the FS/SQLite library just use what it wants.
You could implement an SQLite Virtual File System for your non-volatile memory.