We Keep Coding

EF second transaction get Underlying provider failed on open

This is prior to EF 6. My company has a process that works with all of our other clients expect one. The process opens a connection to the clients database, reads out 1000 records at a time, and commits it to our database.
For this client, we read and commit the first 1000 records just fine. When it starts to read again I get "Underlying provider failed on Open". I understand that EF transactions open and close for each read, so when it tries to reopen the connection to do the next read is when it is failing.
Details: We connect through a VPN to the client database.
The code flow is:
connection.open()
create datareader
while datareader.read()
get 1000 records
bulk commit
db.SaveChanges
get next 1000 records
and so on until it gets all records
After the first SaveChanges is when we get the error.
Any help is appreciated.

Prior to EF6 the DbContext was closing the connection when it was getting disposed regardless whether it owned it or not. Starting from EF6 the context honors the contextOwnsConnection flag passed to the constructor (see here). It's not clear from your pseudocode how you instantiate the connection and the context, so presume you create the context in the loop and pass the opened connection. If that's the case you have a few options:
Upgrade to EF6, or
Use only one DbContext for all the saves, or
Load all the records into memory and process them in chunks each in it's own DbContext, or
Load them in chunks and process them in chunks
If you avoid using the same context for your processing for performance reasons, you can use .AsNoTracking(). There is an article on MSDN on EF performance tuning in case you need more.

Thanks for everyone's help. Turns out that the connection being lost was to our database and not the client's. Not entirely sure why, but what seemed to help was putting our BulkInsert method to create the SqlBulkCopy object inside of a using block. We also, at the point at which it failed, reestablished the connection. It's a little hacky, but it's working.

Connection still idle after close

I've a C# client application that need to checks a table on a Postgres db every 15 minutes. The problem is that I need to install this client into more or less 200 client so, for that I need to close the DB connection after the query.
I use .Close() method but, if I check on pg_stat_activity table on Postgres DB, I can see the connection still open in IDLE status. How can I fix that issue? Is it possible to close definitely the connection?
thanks,
Andrea

Like most ADO.NET providers, Npgsql uses connection pooling by default. When you Close() the NpgsqlConnection object, an internal object representing the actual underlying connection that Npgsql uses goes into a pool to be re-used, saving the overhead of creating another unnecessarily. (See What does "opening a connection" actually mean? for more).
This suits most applications well, as it's common to want to use a connection several times in the space of a second.
It doesn't suit you at all, but if you include the option Pooling=false in your connection string, it will override this default, and Close() will indeed close the actual connection.

Transfer SQL to MySQL C# Monitoring Program

I currently have a working program that is monitoring a few SQL tables and transferring data to MySQL tables. Essentially, I have a loop that checks every 30 seconds. My main concern is that I currently need to close and open the connection every time I loop. The reason for this is because I was getting errors about multiple transactions. When I close my connections, I also need to dispose the connection. I thought that disposing the transactions would have solved this problem, but I was still getting errors about multiple transactions.
This all seems to be working fine but I was wondering if there was a better way to do this without closing the connection.

I am not sure about your errors but it seems that you have to increase the number of connections to the remote computer. Have a look here http://msdn.microsoft.com/en-us/library/system.net.configuration.connectionmanagementelement.maxconnection.aspx
Also you can try to do is use only one connection to realize multiple SQLs.
If it is doesn't help then please provide your code to check it...

Were you committing your transactions in your loop? transaction.Commit() ... that could have been the issue... Hard to say with no code. No need to worry about opening and closing connections anyways since ADO.NET uses connection pooling behind the scenes. You only actually 'open' a connection the first time, after that is kept open in the pool to be used again. As others have said though, Post some code!

Entity Framework database connection question

We are using .Net Entity Framework to do our database related work. Our database is Sybase SQL Anywhere.
using (AndeDBEntities db = new AndeDBEntities(decryptConnStr()))
{
}
We use a lots of above statements to access database. My questions are do we need to close the connection each time after the access is done and how to do that?
At one time I saw "Database server connection limit exceeded" error. I am wondering there must be something wrong in our database connection code.

The connection should be closed automatically. It's possible that there is a resource leak in the Sybase EF supporting classes.
See Managing Connections for more information. Note that (by default) EF will open and dispose a database connection for each query or SaveChanges call. If Sybase's supporting classes do not handle this well (e.g., with a connection pool), then a resource leak may become noticeable when it would otherwise not be.
So actually the using statement does not close the EF connection (unless you've manually opened it). It should have already been disposed (released to the connection pool or closed) before reaching the end of the using statement.

The using statement will make sure that db will get disposed and the connection closed.
Grz, Kris.

No, you are wrapping the AndeDBEntities object in a using block with means its Dispose() method will be called when it goes out of scope (as it implements IDisposable). This method will clear all of the unmanaged resources aquired by the object (assuming it has been developed without a leak - which, I think, is a fair presumption).
I don't believe this is the route of your connection limit error. Do you have the developer's edition? This is only licensed for 3 connections.

Windows mobile Compact Framework SqlCeConnection

I'm hearing that is better to have one connection open upon app start up and closing it when the app shuts down.
What kind of issue can occur having multiple connections ?
Any articles out there that it is best practices to have one connection?
What are your experience with sql ce?

In our SQL CE 3.5 / Compact Framework 3.5 application, we open a connection at startup and keep it open until the application is closed. The database is required on almost every user-interaction in the application and keeping the connection open is faster than opening and closing it on demand.
All data updates are performed in transactions. We Commit the transactions using the CommitMode.Immediate option. This ensures that data changes are immediately flushed to the file, minimising the potential for data loss.

It really depends. For performance, SQL CE works best if there is always a live connection to the database, as the engine doesn't have to build up everything every time you connect.
Having a single connection, however, leads to lazy flushiong of data to the file, and a higher likelihood of data loss or corruption in the event of a catastrophic failure.
I tend to open a "dummy" connection to the database at app startup and have that connection always open but rarely or never actually used. This keeps the engine "primed" if you will. THen for actual data access I use a separate connection and manage state based on what activity I'm doing, typically leaving it open across multiple queries (a pseudo transaction if you will), but not leaving it open indefinitely.