October 7, 2009 at 11:24 am
No, priority boost is not on.
So far so good on the memory changes. Still crossing my fingers.
October 7, 2009 at 12:18 pm
Elliott W (10/6/2009)
Lynn,You don't happen to have the Priority Boost set to ON do you? I have seen that when a server is busy enough and especially when that is set that it won't respond to login requests. I also agree that your login attempt timeout should wait longer, say 30-60 seconds because I believe the default is 15 and on a server that is busy that may be too short.
CEWII
Nope, that is not selected on our server. we still get the error occasionally, but not as often. I made some memory changes as well, but partly for the second instance we use on rare occasions.
October 8, 2009 at 1:54 am
I've often found setting the Delay Validation = true sorts a lot of connection based problems.
February 23, 2010 at 8:19 am
BUMP
We're getting the same error on an intermittent basis. We've already added the entry to the hosts file. Right now the job calls the SSIS package fails and when you rerun the job it completes without any errors.
I'm thinking of building some kind of error trapping into the sql job steps to check for this error. If it finds this specific error then it should just retry the job. Any other errors would require some other intervention to correct the problem. Nothing gets logged at the SSIS package level since the SSIS package did not even start to run.
Just curious if anyone has found a more permanent fix for this.
May 10, 2010 at 10:18 am
I have the same issue. Could you provide the solution?
May 13, 2010 at 7:08 am
Hi P Jones, can you describe more about how to delay validation time?_Thanks
May 13, 2010 at 8:35 am
It is a property of the package. Click on the package in the Control Flow away from other components and look at the property window, you will see it there. The default is false (for don't delay).
CEWII
May 13, 2010 at 8:56 am
Thanks!
😎
February 10, 2011 at 1:20 pm
Same issue.
HOSTS entry is already in place.
Error started occuring for the past 2 weeks.
This is running in a maintenance plan.
Executed as user: USERNAME. Microsoft (R) SQL Server Execute Package Utility Version 9.00.4035.00 for 32-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 2:00:14 AM Could not load package "Maintenance Plans\DB Maintenance - SysDB" because of error 0xC0014062. Description: The LoadFromSQLServer method has encountered OLE DB error code 0x80004005 (Unable to complete login process due to delay in opening server connection). The SQL statement that was issued has failed. Source: Started: 2:00:14 AM Finished: 2:01:03 AM Elapsed: 49.625 seconds. The package could not be loaded. The step failed.
I just modified the property described, will report back to let you folks know.
UPDATE: The fix did not resolve the problem.
Executed as user: USERNAME. Microsoft (R) SQL Server Execute Package Utility Version 9.00.4035.00 for 32-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 2:00:13 AM Could not load package "Maintenance Plans\DB Maintenance - SysDB" because of error 0xC0014062. Description: The LoadFromSQLServer method has encountered OLE DB error code 0x80004005 (Unable to complete login process due to delay in opening server connection). The SQL statement that was issued has failed. Source: Started: 2:00:13 AM Finished: 2:00:53 AM Elapsed: 39.828 seconds. The package could not be loaded. The step failed.
UPDATE 2:
It turned out to be a file system backup job holding things up, not sql.
June 19, 2011 at 10:03 pm
Hi
I had same issue - tried the package delay_whatsit setting , no good.
Tried the addition to the hosts file - no good.
Went back and changed settings back to original & removed the new hosts file entry.
In the end I got cranky, I opened the SQL job that runs the package, went to the job step that runs the package, went to Advanced and set "Retry attempts" to 4 ( could be more if needed ), with Retry Interval set to 0 ( so it retries immediately and cant time out ).
I sat there for a while muttering "now run, you mongrel...."
Now it works fine.
BTW, I'm using SQL 2008 R2 with CU3. Server is in a DMZ, which means authentication is often delayed or slowed down a lot as it has to authenticate for all its jobs back through the firewall.
Modifying the retries means that instead of it failing immediately, it keeps trying and eventually works.
Hope this helps.
I still think SQL 2008 & SQL 2008 R2 have authentication issues.
Cheers
SG.
June 23, 2011 at 3:19 pm
'Retry attempts' works for me, thanks for your input 🙂
July 21, 2011 at 3:15 pm
Were getting this error, too, but for us it was for a totally different reason. Our SSIS package was stored in msdb and run from a SQL Agent job. We had created the SQL Agent job in our development server, where it worked fine, and we scripted out the SQL Agent job.
We deployed the SSIS package and the SQL Agent job script to our staging server, and it worked fine. Then, we deployed the SSIS package and the SQL Agent job script to our QA server, and it worked fine. Finally, We deployed the SSIS package and the SQL Agent job script to our production server, and it worked fine for two nights and failed the third with the 'Could not load package "XXXXXXXX" because of error 0xC0014062' error.
Turns out that when we created the SQL Agent job in development, the SSIS job step had the name of the development server as the "Package Store." Thus, when we deployed to all the other servers, instead of loading the SSIS package from the local server, they were always loading the package from the development server. Because we had set up the package to use "Configuration type = SQL Server" based on the current server name, the package would run with the proper connections and not cross-contaminate data. But, it failed on the third night in production because our network admin had tightened up the firewall between our DMZ where the production server is and the internal network where our development and testing servers are. So with the firewall closed, the production server could no longer load the package from the development server, and, thus the 'Could not load...' error.
To fix it, we just went back to the development SQL Agent job's SSIS job step, changed the Server for the Package Store to "(local)", scripted it out, and re-deployed the SQL Agent job from the new script. Now our production SQL Agent job is able to load and run the SSIS package.
Sincerely,
Daniel
Viewing 12 posts - 16 through 26 (of 26 total)
You must be logged in to reply to this topic. Login to reply