I’m running into some issues with my application that uses SQL Server 2005 Developer Edition. My program creates multiple threads that need database access, and each thread gets its own connection to the database. I understand that ADO.NET has built-in connection pooling to manage this stuff automatically. However, I keep getting OutOfMemory errors when my app is running. The weird thing is that when I remove all the database connection code and run the same application without any DB calls, everything works perfectly fine and no memory errors occur. This makes me think there might be some kind of limit on how many connections SQL Server 2005 Developer Edition can handle at once. Does anyone know if there’s a specific connection limit I should be aware of? I’m trying to figure out if this is causing my memory problems or if I need to look somewhere else for the root cause.
interesting issue! what’s your connection pool size set to? and how many threads are you running exactly? the problem might not be sql server’s limits - could be how you’re disposing connections.
SQL Server 2005 Developer Edition handles 32,767 concurrent connections, so that’s not your problem. The memory issues scream connection management problems. Connection pools max out at 100 connections per unique connection string by default. When that fills up, new requests just sit there waiting or timeout. I’ve seen this exact thing in multi-threaded apps where connections weren’t getting released back to the pool properly. Sure, you think ADO.NET handles it all automatically, but connection pooling only works when you actually close or dispose connections. Double-check how you’re disposing connections and maybe add some connection string monitoring to see what’s really happening with pool usage.
dev edition has no limit wht you might expect. sounds more like a connection leak - are you closing connections or using using statements? trust me, unreleased connections will eat memory like crazy.