I am using Visual Studio 2017 to create an Entity Framework for my database in Microsoft SQL Server 2014.
I created many stored producer to manipulate that database tables and add those procedure to my Entity Framework designer.
So, Is there any way to call stored procedures to manipulate the data without auto-commit ?
I solve the problem by:
1. disable auto-commit from SQL Server.
2. Begin a transaction in the database transaction scope from C# code behind and use transaction.Commit() if the scope successes and transaction.Rollback() if any exception appears.
Related
I am using EF 6.1 and VS 2012 to create a Code First data model basically following the Code First module in Julie Lehrman's EF5 Pluralsight video. It appears to be working just as advertised except I can't find the data file anywhere. I can access it in code, but by no other method.
I am using the LocalDb default connection factory. The database does not appear in the Sql Server Object Explorer under (localdb)v/11.0. There is no mdf file anywhere in the solution or my user folder. Where did Entity Framework put the data?
Maybe looking at the connection string in the debugger will help you find it. Take a look at the Database.Connection.ConnectionString property of the Context you new up.
EF generates a different default connection string depending on the context it's ran in, so I can't tell you for sure where it'll be.
The relevant source code for generating the localdb connection string is here
LocalDb databases have a default location (C:\Users\xxxx\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\v11.0), and you can open MSSQL Management Studio against them with the connection string "(localdb)\v11.0" and Windows authentication.
See http://blogs.msdn.com/b/sqlexpress/archive/2011/10/28/localdb-where-is-my-database.aspx
So I've started a SQL Server database project inside VS 2012. I have done this for other databases already but not related to Service Broker.
For testing I had already created db, queues, etc through a T-SQL script including Message Types which was in an XML format. i.e.
[//blah.com/Items/RequestItem]
When I try to do something like this in the DB Project it's not allowing me too due to special chars.
Anyone done this? Gotten around it?
Is there a way to simply put my already created T-SQL file in the database project and have it use it?
See my comment above. I was able to import the script by Right clicking on the database Project.
Entity Framework 6 ships with the SqlAzureExecutionStrategy which will retry on exceptions that are known to be possibly transient when working with SqlAzure.
Will this strategy also work for normal desktop Sql Server (non azure sql server) ?
I'm in the process of migrating our on-premises hosted ASP.NET application into the cloud and I'm running into an issue with the migration of my database.
We're using EF5 for database interaction and we've enabled the code first migrations in order to deal with database changes. However, whenever I generate a BACPAC file the __MigrationHistory table is ignored and when I use the SSIS tool to migrate data between my local and Azure database the values in the identity columns are changed regardless of whether I select 'enable identity insert', messing up my entire database.
What am I doing wrong here? I've tried various routes and none seem to have the desired effect.
Thanks,
Patrick
I am using ADO.NET Sync Framework and on the client side (PDA running Windows Mobile 5 and .net cf 3.5 and SQL CE 3.5). Server side is using SQL Server 2005.
On server side manual queries have been written to determine which records are selected for insert/update/delete for each client as well as any conflicting records.
On PDA though, I can't seem to find a way to determine exactly which records were synced successfully and which failed. I can obtain the SyncStatistics but this just gives totals and I need actual row id's so that I can delete the successfully synced records off the PDA.
Any ideas?
Are you not having a event handler for ClientApplyChangeFailed? You can use this for logging the failures.