I'm building a small ASP.NET MVC site where I want to use SQLite. While I already know how I will be connecting to the database (using DbLinq), I don't understand how to put the ASP.NET tables generated by aspnet_regsql.exe into an SQLite database.
I've used the regsql tool before with SQL Server, but never with SQLite. How do I create them for the SQLite DB?
One strategy that I think might somehow work is:
Use aspnet_regsql.exe to create the tables into an empty SQL Server database
Script all the objects in the database into T-SQL
Apply the T-SQL to the SQLite DB (how?)
Take a look at http://salient.codeplex.com
the Web.SQLite directory contains a drop in replacement for the default SQL providers.
It was a proof of concept that turned out ok. It uses EF, so is not as performant as it could be but should service low/medium traffic sites without issue.
You should be able to exclude all other files except that subdirectory and build it in isolation if desired. This will allow you to also trim the references.
Let me know if you have any issues.
You could try it with SQL Server Compact Edition 4 which is an embeddable SQL engine like SQLite but has an easier upgrade path if you need to grow it up to SQL Express or SQL Server.
Unfortunately the aspnet_regsql will not work with SQLite, so your strategy is essentially the correct approach. However, I would suggest looking at something like Roger Martin's Gallery Server Pro, which uses SQLite and already has the Membership, Role, and Profile provider tables scripted. You can make use of the script. See Roger's Code Project article from more information.
Related
I'm using EF Core to access CDC tables within system tables in SQL Server, but command ef scaffold does not find the tables. I do access tables out of system tables successfully.
I've tried to grant table to dbo owner, without success.
Stack
SQL Server 2016
EF Core 3.1
I don't think you can use the CDC tables directly, and I would probably recommend against it since they can change between SQL Server versions.
If you really want to use them, you could create one or more views over the top of the CDC tables and use them instead. That way EF will pick them up and they are somewhat future proof if the tables change since you only need to change the views instead of fix and recompile your code.
Hi I have source SQL DB and destination RDS PostgreSQL DB.
I want to migrate by using flyway. First is it possible ?
If possible then can anybody help me with solutions?
Flyway is a tool for running scripts, rollbacks, targeted piecemeal deployments, all sorts of other stuff. However, it doesn't generate scripts. You have to provide it with syntax appropriate to the database system you're deploying to. T-SQL isn't the same as PostgreSQL. Nothing in Flyway will allow you to translate the T-SQL. You will have to do that work on your own. Once completed though, Flyway will absolutely be able to deploy those changes to your new database.
I have a application written long time back using the MS Access as the configuration database. It was using OLEDB Provider (Jet Engine) for retrieving data from the configuration DB.
I intended to replace MS Access Db lightweight RDBMS which requires no additional installation requirements. Thinking of using SQLLite which seems to suite my needs. Wanted to check if anyone have invovled in migrating the data from MSAccess to SQL Lite. Is there an easy way to migrate the schema and data?
You can quite much transfer data and schema if you setup the ODBC driver for sqlite.
Once done then you can run append queries in Access to export to the sqlite database.
Of course with sqlite you don't get or have forms, reports or a coding language. So, you have to replace that part of Access with some other kind of development platform.
So, you need to get a ODBC driver for sqlite.
This one works well:
http://www.ch-werner.de/sqliteodbc/
So, once you done the above, then you can link from access to sql lite. You can even edit data with Access forms, or even run access reports against data in sqlite.
I am creating a ASP.NET application that is pretty much self contained, it will be pushed to different hosts and as a result will include an embedded database engine - I did look at SQLite but that can not run under medium trust and that could be an issue, so it looks like it is going to have to be Microsoft SQL Server Compact Edition 4.
Microsoft SQL Server Compact Edition does not support stored procedures and because of such I'm wondering where the best place to include the SQL code would be, taking into account future edits, etc.
So far I think that my options are either directly embedded in the code as a String or Stringbuilder type (which can get messy for advanced queries), or maybe in SQL files stored in the App_GlobalResources folder - the second option is something something that I have only just considered, but think that that would be a pretty good option for containment and future editing - does anyone have any other suggestions?
Regards, Nathan.
You can store parameterized queries in your resource file.
You can use MS SQL Express. It is free, it has stored procedures, but it has 4GB database size limit (increased to 10 GB for SQL Server Express 2008 R2).
For more information read this.
I think it's better to use some ORM tool or LINQ to SQL, than store native SQL strings.
Like other have said an ORM, Entity Framework or Linq to SQL is probably better than inline SQL, however as your question wasn't asking about any of these I would suggest storing you SQL files as embedded resources. Others have mentioned resource resource files but I feel that resource files are difficult to use and you do not have an nice IDE to develop within. Having embedded .SQL files should be easier to version control, use within Visual Studio, allow you to keep your queries as closely as possible to your data access components and make it difficult to change once in a production environment.
in my web site i have two databases, ASPNETDB.MDF and a self created one (database.mdf). (The don't contain a lot of data yet)
But i need a relationship (foreign key) between a table in ASPNETDB.MDF and a table in database.mdf.
So i guess i need to merge both databases first, would you just extend the "ASPNETDB.MDF" with the tables from "database.mdf" ?
or better configure "database.mdf" for the asp.net Applicatoin Services and then delete "ASPNETDB.MDF" ?
Is "ASPNETDB.MDF" even meant to be used in a production online web application?
(Right now i'm using sql server express but i will probably use sql server when deploying Site to a shared host)
thanks a lot for answers
the scripts for the structure that is inside ASPNETDB.MDF are deployable on a different database (http://msdn.microsoft.com/en-us/library/x28wfk74.aspx)
however, I would really consider wether or not you want to do a foreign key to those tables, the membership, roles and profile API is intended to be used as a pluggable API, something you will break by defining your foreign key
Setting up membership in existing database is something you should be looking at. If you are asking me, I will and I have created membership related data objects in my application specific database. You can find the SQL scripts to do so at C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727(v4.0.30319 in case you have VS 2010).
By doing this you can create foreign keys to membership table and achieve your objective.