I am using entity provider & sqlclient provider targeting same sql server in a single transaction scope. I am getting below error:
Network access for Distributed Transaction Manager (MSDTC) has been disabled. Please enable DTC for network access in the security configuration for MSDTC using the Component Services Administrative tool.
I dont want to escalate to msdtc as only one sql server is being used. Please suggest.
A distributed transaction is required if more than one SqlConnection is used, regardless of the number of servers and databases. This is because each connection has its own SQL session that can be independently committed and rolled back. If you have more than one connection then a distributed transaction coordinator is needed to coordinate the two separate transactions.
If you don't want to escalate then you can only use one connection in the transaction.
Related
I am working on a project to replicate an application that currently runs on premises to an Azure SQL Database. For the foreseeable future, the application will have to run both on site and on Azure. The project is stored in TFS, and multiple filegroups are specified. Development is ongoing. Is there a way I can maintain this as one project in source control, given that Azure SQL databases only have a primary filegroup? I feel like I can't be the first person in this situation, but I haven't found a decent solution yet.
I'm fine with the Azure database only running on primary, but that is not an option for the local database. This is not for a single deployment, I would like to continue to deploy changes both locally and to Azure from source control. I may be asking for too much here, I just really really want to avoid dual maintenance, when there are a number of teams involved.
Thank you!
You have two options:
Add manual SQL Statements to setup Filegroups on your on-premises SQL Server that don't run against SQL Azure
Use a new feature of Azure named SQL Managed Instances. This is fully managed SQL Server instance running in Azure that supports all features of SQL Server such as filegroups. Don't go installing your own SQL Server on IaaS. That's not necessary anymore with this new feature.
There is no way to use multiple filegroups in Azure SQL Database. If you want to move your database to the cloud and keep the ability to use multiple filegroups, please consider setting an Azure VM with SQL Server on it. Another option would be to change your application so that it does not use SQL filegroups.
As for the replication, please consider SQL Server replication or Azure Data Sync. Azure Data Sync requires an Azure SQL database. It is slower than SQL Server replication but it can handle conflicts.
I am new to the MVC world, i am developing an mvc5 code first from database project which i want to to create securely connection between my local server with more than one sql servers, and each server can contains one or more databases.
so can someone clarify me these:
1. Creating SQL Server Connections[if possible in one entity framework]
2. Securing the Connections.
3. if possible how to access the database other then the initial catalog database
Note:
i found to use entity framework to data access , after creating connection then encrypt the connection string by command-line utility, Aspnet_regiis.exe
any other techniques rather than this.
Thanks
As far as securing connections go, all you've got is SSL. Make each SQL Server instance only available via SSL and your connection is as secure as it will ever be. Encrypting the connection string, using a limited access user, etc. are important, but aren't really aspects of securing the connection, merely security in general.
For multiple database access via Entity Framework, you just need multiple contexts. Each context belongs to one and only database, but you can have as many contexts as your want. The only thing to be somewhat mindful of is having multiple contexts that you run migrations against. While I believe EF has supported this since version 6, it's still not recommended. Generally, you should only have one context that you run migrations against (the entities that inherently belong to your application), while your other contexts will merely work with existing database created and managed outside of your application. Really, if you think you have a need for multiple migrate-able context in a single project, that's really an argument for splitting up your project into multiple projects.
So, for connecting to an existing database, you just need a regular old DbContext subclass, with a couple of tweaks: 1) you need to specify the connection to use manually and 2) you need to disable database initialization. Here's a skeleton of what that looks like:
public ExistingDatabaseContext : DbContext
{
public ExistingDatabaseContext()
: base("ConnectionStringName")
{
Database.SetInitializer<ExistingDatabaseContext>(null);
}
// DbSets here
}
First off, I know the best-practice is to use a single database user account in your web app to take advantage of connection pooling to keep the app nice and responsive. However, due to the REQUIREMENTS (as in no changing this under any circumstances), I must authenticate each user with his or her database account.
The context is a warehouse management application that runs on Android, but gets its data from web services that I'm probably going to write in Grails unless a suggestion here shows me a tech more suitable for my requirements. Due to the nature of the application, the users would likely only need to authenticate once or twice a day, so I was thinking I could simply persist the Connections in a HashMap keyed by the hash code of the username concatenated with the password. That should allow the application to maintain the same or similar performance level as the best practice.
Now, my issue is in using the persisted Connection objects. I know that I will not be able to use them with GORM without a significant amount of customization, so I was planning on using them with groovy.sql.Sql, which works out well because most of the business logic is in PL/SQL packages anyway.
My question is how does the groovy.sql.Sql class deal with its Connection object? Will I run into issues of Connections being closed by it, or can I safely use my HashMap to persist the Connections?
groovy.sql.Sql will not close your connection. In the class spec you can find:
If this SQL object was created with a Connection then this method
closes the connection.
So SQL class is really if you want to do things by yourself, not trusting entirely on Hibernate. Although, I think you can use Spring's UserCredentialsDataSourceAdapter for your solution. It uses ThreadLocal to set credentials for each thread, so the call to: UserCredentialsDataSourceAdapter.setCredentialsForCurrentThread(String username, String password)
would solve. There are other aproaches you could try here.
I actually just found something that future visitors to this question may find useful. While digging into the Spring Framework's documentation, I discovered that their JDBC Extensions actually implements proxy authentication (where a proxy account is used to establish the connection, but an actual account is provided for the context of SQL execution). Unfortunately, the implementation as of 8/17/2012 does not support using passwords for users over the proxy connection, so it won't be usable for me currently, but anyone finding this question should check to see if that is still the case. Here are the links:
JDBC Extensions Docs v1.0.0.RC1
JDBC Extensions Docs Base
I'm searching for information on database connectivity (Firebird in my case) with IntraWeb Applications.
I especially need to know the difference(s) involved in using the database on the TDataModule with LockDataModule function, or using the database on the UserSessionUnit.
For example i need to have the database totally disconnected if no users are using the server, and at most 30 users will be connected.
I may at worst have to connect to some old paradox Database and i need a structure that could handle that (i know that i'll have to generate a folder based on WebApplication.AppID to handle sessions). At worst...
Thanks in advance for any piece of information or useful links you could provide me ^^
Scenario 1 - You leave "Pool Data Connections" unchecked in the Intraweb Application Wizard
In this scenario the wizard creates a ServerController, a UserSession but not a DataModule. You place your database, session and dataset components on the UserSession.
Whenever a new user connects to your website a new instance of the UserSession is created and a connection to the database is made. When the ServerController.SessionTimeOut expires due to user inactivity the UserSession is destroyed and that particular connection to the database is severed.
For 30 concurrent users this model will probably be fine for you and should guarantee that all database connections will be severed when the website is not in use.
Scenario 2 - You check "Pool Data Connections" in the Intraweb Application Wizard
As well as the ServerController and the UserSession the wizard will create an empty DataModule. You place your database, session and dataset components on the DataModule.
The ServerModule has a TIWDataModulePool component on it which has PoolCount property.
When your application starts it creates PoolCount instances of the DataModule each one of which makes a connection to the database. As your pages require database access they call LockDataModule and UnlockDataModule to temporarily make use of one of the DataModule instances from the pool.
When your application closes the DataModule instances in the pool are destroyed and their connections to the database are closed.
This model is appropriate when having an open database connection per user would exceed the capabilities of your database server. For just 30 users connecting to a FireBird database I don't believe it would be required.
You may want to consider using a component set like kbmMW by http://www.components4programmers.com/ I have used this for years with Desktop apps ans now with IW apps. I deploy my apps as Services and currently having a few issues deploying as an ISAPI. kbmMW is well suited for an app with lots of connections as it offers connection pooling etc... It has many features and benefits. Check out site for yourself.
I use the Enterprise version, though I think the free version may be useful to you.
Cheers!
-Lou
I’m researching EF4 for a new in-house application development project using .NET v4, EF4, & SQL Server 2008 R2. To date, our small dev team has done very little .NET development and only demonstration EF applications. Our current applications use DB app-roles for security and that's worked out well for us.
From reading and some basic experimentation, my understanding is:
EF can open and close DB connections as needed. However it is possible to manually open and close an EntityConnection for use by the EF ObjectContext.
SQL Server app-role security requires running sp_setapprole on DB connections to set the application role context. sp_unsetapprole can be used to revert a connection to its original context.
By default, DB connections are pooled. Using sp_setapprole with connection pooling can be problematic if the connections are not restored to their original context before being returned to the pool.
If all the above is correct then the obvious way to use EF4 with app-roles is to manually open & close the EntityConnection, being sure to execute sp_setapprole after opening and sp_unsetapprole before closing.
Is there a better way? I'm mostly concerned about accidentally closing the connection without first calling sp_unsetapprole. Seems like an error that may not be noticed immediately.
You can just add "Pooling=false;" to your store connection in the app.config (Provider Connection String). If you don't actually need pooling, this seems to be the simplest solution.