Does SQLite for WinRT support foreign key constraint ? Can you please guide me on this ? Thanks.
Let me preface that I have not tried this, however, these two references (on sqlite.org) would indicate yes. If it's not working, provide some additional info as to what errors/behavior you are seeing.
SQLite version 3.7.13 adds support for WinRT and metro style
applications for Microsoft Windows 8. The 3.7.13 release is coming
sooner than is usual after the previous release in order to get this
new capability into the hands of developers. To use SQLite in a metro
style application, compile with the -DSQLITE_OS_WINRT flag. Because of
the increased application security and safety requirements of WinRT,
all database filenames should be full pathnames. Note that SQLite is
not capable of accessing databases outside the installation directory
and application data directory. This restriction is another security
and safety feature of WinRT. Apart from these restrictions, SQLite
should work exactly the same on WinRT as it does on every other
system. (2012-June-11)
and
This document describes the support for SQL foreign key constraints introduced in SQLite version 3.6.19.
3.7.13 > 3.6.19
SQLite supporting relationship constraints is one thing - the wrapper you'll use in your app supporting it is another.
I think there are today two drivers :
SQLite-net : ORM style with object to DB mapping, LINQ support but NO FOREIGN KEYS support
sqlite-winrt : Relationships constraints support, but you'll do everything by hand. Bascially, it supports connecting to a SQLite DB, executing queries and fetching results.
I'm looking for a better driver right now by the way, if someone knows one I'd be glad to know about it !
HTH
Related
When dealing with MSSQL, there are loads of options for how to add the schema (including indexes) into version control (database projects, Redgate SQL Source Control, etc.), but we're looking to introduce Couchbase into our application, and I'm looking for a way to add indexes into version control (currently using Git with TFS).
We've got multiple environments (test, staging, live, etc.), and we're going to want to make sure we deploy the same index changes to each Couchbase cluster set up for each environment.
How do we ensure that we can bundle Couchbase index alongside a specific release, or does this need to be a manual job?
Assuming we're talking about N1QL indexes, you can create them using N1QL syntax as documented here: https://docs.couchbase.com/server/current/n1ql/n1ql-language-reference/createindex.html
So you could do this programmatically, either using the query support in the SDKs or the REST interface directly.
In addition, we have SDK wrappers around these. There are some hints on how to use them with Java SDK 2.x here: https://docs.couchbase.com/java-sdk/2.7/n1ql-query.html#index-building, but we are aiming for more complete documentation in this area for 3.x. I will update once they're available.
Nowadays SAP recommends to "keep the core clean" in order to be able to move to the cloud and always be able to update to the latest version without having to worry or retest, also valid for on-premise.
I got the requirement to add a Z field to the QMEL table to link its notifications to SAP PS projects (PROJ table). The QMEL table already has a structure -CI_QMEL- ready to be extended and the related BAPIs support this extension.
But in order to keep the core clean, I'm considering to challenge the functional requirement and suggest to create a ZNOTIF_PROJ table with the same key than QMEL (Notification ID). This would then become totally separated from the standard but at the same time the official BAPI wouldn't be able to support it, so a wrapper on top would be needed to update the standard and the custom and everything would become more complex.
Should I stick to the old extension style or go for a new table?
Personally I prefer extending standard tables. Having BAPIs, standard transactions, etc, work as expected is worth far more than a nebulous idea like a "clean core."
As long as you're not modding core code or extending tables in an incorrect manner, customizing the system in ways supported by SAP is not a bad thing. You should consider your future upgrade plans (S/4 on-prem vs cloud, for example) when deciding the right answer, but don't make things too hard on yourself.
S/4 on-prem or cloud already has adding new fields and tables functionality. We can do this in web UI look like SAP CRM. So there is no problem for extending existing structure. Help page about this functionality here.
Imagine an application which is supposed to work with different database vendors. As we all know the syntax for SQLs (especially DDL) is not portable. How do you deal with maintaing the SQL scripts?
Until now I see three options:
to store SQLs in format of one of the databases and have a tool which automatically converts from one syntax do another (do you know such tools?)
to store SQLs in some artificial language and a have a tool which is able to generate vendor-specific SQLs on demand (any recommendation here?)
to store SQLs in many database formats neglecting the redundancy (this is the worst one, isn't it?)
Do you recommend any of them? Do you have a better idea?
The development environment tries to follow the continuous integration principles, so automation is a key feature here.
Have a look at Liquibase (that's essentially your second item on the list)
http://www.liquibase.org
It's not perfect (e.g. it does not support check constraints) but it is quite useful
This video shows a solution using the Subsonic project http://subsonicproject.com/docs/Using_SimpleRepository and its data migration capabilities. The strategy is to use a general language and apply it to different databases.
Hope this is what you were looking for
Use some kind of ORM framework with schema generation capability.
The dev tools for SQL in Visual Studio are great.
Is it possible to develop an app for Microsoft SQL Server, and then deploy a MySQL-compatible database instead?
The dev tools for Microsoft SQL Server are really nice (i.e. LINQ support), but a MySQL-compatible column database has better performance for huge datasets.
You would need to use MySql .net connector
http://dev.mysql.com/doc/refman/5.1/en/connector-net.html
With this, you get some of the functionality that you have with SQL server (entity framework, designer, etc) there are still a bunch of things that are not supported, but it's a good start
It's possible, but a number of specifics might tend to prevent a full implementation on SQL Server, particularly with respect to stored procedures.
However, if the intent is to build a scaffolding on VisStudio and finish the development using the MySQL tools, it would work okay. You'll have to learn both SQLs quite thoroughly. The sooner you do that, the less grief there will be in the conversion.
One method for doing this would be to abstract away the database itself. That be done at least a couple of ways; the first way, you could use classes to build the SQL that your application requires, and then just use that; then all that has to happen is that it has to know how to generate the right SQL for the right server. One of the drawbacks of doing it that way, though, is that if you depend on functionality that exists on only one DBMS, you'll have to emulate it in that abstraction layer.
The other method that you could use is to create two versions of your classes that talk to the RDBMS, one for MySQL and one for Microsoft's SQL Server. Use an interface and derive from it in order to do the actual implementation. Of course, you'll want to make sure that the only responsibility of the class is to interact with the database, so if you're doing this for business layer objects, you'll be implementing those sorts of things with two classes: a low-level one for the database API, and a high-level one for actually providing the API that your application is going to consume.
Perhaps not a direct answer to your question, but the dblinq project may be of use to you.
It may be worth a look just to see the MySQL implementations within the project in order to determine what the real differences between SQL Server and MySQL are going to be and how they're going to affect you. The more you can abstract out those differences behind a dependency implementation, the easier it'll be to swap out one implementation for another.
You can write your code for SQL Server and then switch to Devart LinqConnect.
For example, you can create a LINQ to SQL model using Entity Developer (in VS integration mode or in standalone mode), then change the connection to the MySQL-specific one and run Update Database from Model wizard (don't forget to select the Regenerate Storage check box).
As a result, you will obtain a MySQL database, having structure identical to the SQL Server one.
I am looking for good embedded database that i can use for application developed using Qt. The applications target desktop users from various sites of a single large company. The database should be able to store data separately at each site and the data shall be merged with other sites as and when it is required.
Besides SQLite, any of the following will work with Qt as an embedded database. Qt already has drivers for most of them, and you can find drivers for others. In terms of merging data "with other sites", it all depends on what you mean by this. Replication solutions for SQLite and MySQL Embedded may not be great (or exist at all). I would probably go with Firebird or Berkley.
Firebird
MySQL Embedded
Berkley DB - Qt plugin can be found at http://sourceforge.net/projects/qbdb/
If interested you can find more information on various replication support at the following links:
http://www.firebirdfaq.org/faq249/
https://docs.oracle.com/cd/E17276_01/html/programmer_reference/rep.html
http://hrivnac.web.cern.ch/hrivnac/Activities/Packages/Octopus/