ConnectionRead (recv()) error in running data services job

[Former Member]

We have an ETL job designed in BusinessObjects Data Services 3.1. It’s been working fine every day in the morning. We migrated our source database from one server to another server (cluster based), and also from SQL Server 2005 to SQL server 2008 R2.

The same process's done on DEV and QAS and it was working properly. But in production after the migration, the job runs randomly successful, and most of the time the following error occurs:

(12.2) 03-29-12 06:01:02 (E) (2020:5088) DBS-070401: |Data flow DF_DF|Reader TABLENAME_Extract_Qry-JoinCacheReader3                                              ODBC data source <ODBC_DESTINATION> error message for operation <SQLFetchScroll>: <[Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionRead (recv()).>.

(12.2) 03-29-12 06:01:12 (E) (3664:4932) DBS-070401: |Data flow_DF|Reader XXX ODBC data source <ODBC_SOURCE> error message for operation <SQLGetData>: <[Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionRead (recv())

Any Ideas about it?

[Former Member]

I think this has to do with SQL - BODI connection. The possible reasons would be your job taking too long to execute or there is some kind of connection time out issue. Try checking TCP/IP and ports assigned?

[Former Member]

Thanks Arun,

This job totally will not take more than 20 minutes to run, but as I see this week it faild after 59 seconds, the next time 3 minutes, the other time 5 minutes,...Also twice it ran successfully. But, what I wonder it is working in our QAS with the exact same data fine.

I will check TCP/IP and ports. Should it be done on DI sever and database server?

[Former Member]

I am guessing the issue would be as i mentioned above. So what you can do is check this link and see the solution mentioned. http://support.microsoft.com/kb/942861

Also do you have any sql() statement in the query or scripts etc in DI? If you have any such things, i suggest you create a function or stored procedure and call the same in DI for the jobs rather than executing the statements directly from DI.

[Former Member]

Thanks Arun. I'll use your suggestion and let you know.