Ever since we upgraded to the MSSQL version of RE my users have been experiencing daily General ODBC Errors/ Communication Link Failure Errors. The interesting/frustrating thing is that I have been able to isolate the problem to MSSQL apps running under MSDE on Win200 servers. The reason that I know this is because I have another Human Resources app that is also MSSQL/MSDE/on it's own Win2000 server and those users are experiencing the same errors. I can provide screen shots of the actual error messages if anyone has any ideas? HELP. RB Robert Badley Director, Donor Services and IT IVCF Canada

We get a lot of them too, SQL 2k Std, and I played along for a while, following all of the Blackbaud recommendations that never made a difference. My theory is that it has to do with how the programmer connects to the database, and I think they're using an older technology (odbc) than 2000 or 2003 would natively support (oledb or ado.net). It was already in the code using ODBC and making the change to a newer data access scheme is huge for such large software products. Sorry to say, I have no solution for you. We just live with it and hope that in time BB takes care of it.

I've notice several SQL problems out there. As with any database using your disk controllers can give you a fair amount of increased performance. Use the BMC or SQL to move your files to separate disks/controllers or do this with the first installation. Log files take up the least amount of space so look at your drives free space first and move accordingly. Also make sure you always have 33 percent free space on your drives and c: should have a minimum of 700-800 Meg free space or your databases seem to choke. I myself have seen it shut down the databases or get real real slow if it falls below 600 Meg on c:. There is also a little known problem with running your new RE 7.6 and FE 7.2 on a Domain controller. Microsoft was supposed to post this inherent problem. I was told by BB that if it works leave it alone but whenever it is convenient demote your Blackbaud server and keep all Blackbaud databases for these 2 products on anything BUT a domain controller IE (remove and reinstall Blackbaud products). I have it running on the domain controller but have had many problems starting with the installation and the automated backups. RE 7.61 still will not start up automatically after a reboot or remotely after a reboot at all. Standing at the server seems to make the service for RE start just fine. Don’t know exactly why especially since FE 7.2 works. Another thing that most folks don't know is that increasing the default memory allocation may make things worse. When I worked at Microsoft supporting Exchange email we were told to never change the defaults for SQL or Exchange when it comes to running both on one server because it really takes what it needs already for both products and changing the memory usage could actually make things worse. Of course, ideally we would have separate servers for different databases no matter what they are and how they are setup. In the real world adding another processor, memory, and/or separate raid controller/s is what most of us are doing instead of separating our “all in one eggs into another basket”. We doubled our memory lately on the server and that has made a notable increase in performance in response time. We are still waiting on the upgrades on the second processor and the hard drive / raid controller. It’s easy to see that using separate servers is easier on the whole environment by letting the users continue to work on other things if just part of the database systems is down for whatever reason. Brad Giles Systems Administrator The Lamplighter School [Email Removed] Note: ODBC errors is almost always network related issues on the client, server IE unavailable database path etc..., and your LAN typologies. Make sure the service/s are running and then check your network protocols and your mapped drive to the server from the client.

With regards to ODBC errors. I'm presently utilizing the MDSE version and have been receiving multiple errors. I've found a solution which entails setting the auto close option to OFF. From my reading the defaut is ON. Has anyone attempted this route?

Autoclose? Haven't heard of that before - is it MSDE-specific? I'll give it a whirl if you tell me where to find it!

Are you still experiencing ODBC errors? We're utilizing MSDE and cannot resolve any errors. We've exploited all BB suggestions and are stumped.

I've basically given up. It doesn't corrupt the data, nor do I have to reinstall the app, so the damage is limited to user inconvenience. No other sql-based apps in our network have these problems, so it's not the network. Free space (several G free per drive), RAM (1 G), etc., are good on the server, db and app on the same server, no other apps or databases on that server, less than a dozen total users and normally less than 5 concurrent, all maintenance scheduled for at least weekly. I just can't see spending more time chasing ghosts when I have other systems with treatable problems! If anyone does get results out of a BB solution, please post that BB ID here!!

We are running EE on SQL Server 2000 Enterprise SP4, and continue to have these General ODBC/Communication link errors. We run weekly database maintenance, I have followed all of the suggesstions that the support analysts have given us as well. Some of the things i've tried are: Checking network drops and switches for possible issues, checking hardware on the server (NIC's etc.) and checking workstations as well. Everything I have checked is fine, EE and RE are the only programs effected, and we run several other SQL databases on the same server. I was not able to find any issues, yet this continues to happen and our users are extremely frustrated. Is anyone else still receiveing these errors. Telling user's to exit and sign out and sign back in again and telling them to Kill the login manager from the task manager is just not working anymore. Help...

We're running EE 7.61.62.0007, Windows Server 2003, MSDE. Some time back I kept getting ODBC errors. I'm thinking the fix might have involved updating MDAC to the correct version. I'm sorry but I don't recall what the exact fix was and I believe I stumbled on the fix while trying to figure out some other network errors. Our communication link errors had to do with master browser problems and a device (firewall) updating the ARP cache with incorrect MAC addresses for our Blackbaud server. Your issue sounds very similar to ours.