But David, it works without the domain on that other box. (Oh, and the server in this situation is an AIX box.) The client is simply trying to recreate the connection that works on another box.
New information: The memory of the failing box has been expanded to 4G and the customer has installed a version of the UniOLEDB driver that I have working here. In fact, I have this very same UniOLEDB driver plugged in as a linked server in my SQL Server 2008 and it works without drama. The test.udl file as recommended by Colin is now able to make a connection, but that's where it stops. With the linked server configured inside of the client's SQL Server 2005, a query issued against that linked server returns this: Msg 7399, Level 16, State 1, Line 1 The OLE DB provider "IBM.UniOLEDB" for linked server "ADS" reported an error. Access denied. Msg 7350, Level 16, State 2, Line 1 Cannot get the column information from OLE DB provider "IBM.UniOLEDB" for linked server "ADS". I've verified the user ID and password and I'm confident they're correct. And I've tried logging into SQL Server both using Windows authentication and also SQL Server authentication, with no difference. And as I said, I have it working here with SQL Server 2008 and the same UniOLEDB driver. So could there be some weird Windows security issue, maybe something preventing the OLEDB infrastructure from instantiating the UniOLEDB driver? I've checked permissions on the UniOLEDB.dll and that looks all good, i.e. it matches the other server. So given all that, what am I missing? _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
