Job step fails with Error 7399 and 7312

We have a job that intermittently fails on the same step with the same error.
Identical jobs that run before this one always succeed. The step uses the
following T-SQL to update a table on a linked server:
DBCC TRACEON (7300, 3604)
INSERT INTO <linkedservername>.ods.dbo.[!ODSReplicationTimes ]
([Date], Imports, Div)
VALUES (dbo.DateOnly(DATEADD(hh, 7, GETDATE())), GETDATE(), 'wbd')
if the job fails, it is exactly the default timeout of 10 minutes after the
start time, and results in this error:
Executed as user: <username>. OLE DB provider 'SQLOLEDB' reported an error.
[SQLSTATE 42000] (Error 7399) [SQLSTATE 01000] (Error 7312) OLE DB error
trace [OLE/DB Provider 'SQLOLEDB' IRowsetChange::InsertRow returned
0x80004005: ]. [SQLSTATE 01000] (Error 7300). The step failed.
on failure, this step proceeds to a similar step which calls a sproc:
DBCC TRACEON (7300, 3604)
CheckFutureStatus 'JobName Finish','!Check Status WBD',240,240,3,'wbd'
yielding a similar result:
Executed as user: <username>. OLE DB provider 'SQLOLEDB' reported an error.
[SQLSTATE 42000] (Error 7399) [SQLSTATE 01000] (Error 7312) OLE DB error
trace [OLE/DB Provider 'SQLOLEDB' IRowsetChange::SetData returned 0x80004005:
]. [SQLSTATE 01000] (Error 7300). The step failed.
I've set the step to retry 3 times/5 minutes to no avail. the traceon
doesn't give any additional information.
Any ideas?
Hello
Did you try to perform a SQL Profiler trace on the server that you have
configured as the linked server to see what happens on that server. I'm
assuming that the query should finish within the 10 minute timeout period.
Thank you for using Microsoft newsgroups.
Sincerely
Pankaj Agarwal
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
|||What Events/Data would you want to see. anything in particular for this
situation?
"Pankaj Agarwal [MSFT]" wrote:

> Hello
> Did you try to perform a SQL Profiler trace on the server that you have
> configured as the linked server to see what happens on that server. I'm
> assuming that the query should finish within the 10 minute timeout period.
> Thank you for using Microsoft newsgroups.
> Sincerely
> Pankaj Agarwal
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>
|||I think it would be beneficial to capture the Execution Statistics, Stored
Procedure and TSQL related events. Also capture SP Recompile, Database File
Autogrow. This would give you at least a starting point to see what event
is the query stuck on. I would also download the blocker script from the
following KB article and run that to see if there is any blocking when the
query does not complete during the 10 min timeout interval.
271509 INF: How to Monitor SQL Server 2000 Blocking
http://support.microsoft.com/?id=271509
Thank you for using Microsoft newsgroups.
Sincerely
Pankaj Agarwal
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.

Job step fails with Error 7399 and 7312

We have a job that intermittently fails on the same step with the same error
.
Identical jobs that run before this one always succeed. The step uses the
following T-SQL to update a table on a linked server:
DBCC TRACEON (7300, 3604)
INSERT INTO <linkedservername>.ods.dbo.[!ODSReplicationTimes]
([Date], Imports, Div)
VALUES (dbo.DateOnly(DATEADD(hh, 7, GETDATE())), GETDATE(), 'wbd')
if the job fails, it is exactly the default timeout of 10 minutes after the
start time, and results in this error:
Executed as user: <username>. OLE DB provider 'SQLOLEDB' reported an error.
[SQLSTATE 42000] (Error 7399) [SQLSTATE 01000] (Error 7312) OLE D
B error
trace [OLE/DB Provider 'SQLOLEDB' IRowsetChange::InsertRow returned
0x80004005: ]. [SQLSTATE 01000] (Error 7300). The step failed.
on failure, this step proceeds to a similar step which calls a sproc:
DBCC TRACEON (7300, 3604)
CheckFutureStatus 'JobName Finish','!Check Status WBD',240,240,3,'wbd'
yielding a similar result:
Executed as user: <username>. OLE DB provider 'SQLOLEDB' reported an error.
[SQLSTATE 42000] (Error 7399) [SQLSTATE 01000] (Error 7312) OLE D
B error
trace [OLE/DB Provider 'SQLOLEDB' IRowsetChange::SetData returned 0x8000
4005:
]. [SQLSTATE 01000] (Error 7300). The step failed.
I've set the step to retry 3 times/5 minutes to no avail. the traceon
doesn't give any additional information.
Any ideas?Hello
Did you try to perform a SQL Profiler trace on the server that you have
configured as the linked server to see what happens on that server. I'm
assuming that the query should finish within the 10 minute timeout period.
Thank you for using Microsoft newsgroups.
Sincerely
Pankaj Agarwal
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||What Events/Data would you want to see. anything in particular for this
situation?
"Pankaj Agarwal [MSFT]" wrote:

> Hello
> Did you try to perform a SQL Profiler trace on the server that you have
> configured as the linked server to see what happens on that server. I'm
> assuming that the query should finish within the 10 minute timeout period.
> Thank you for using Microsoft newsgroups.
> Sincerely
> Pankaj Agarwal
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>|||I think it would be beneficial to capture the Execution Statistics, Stored
Procedure and TSQL related events. Also capture SP Recompile, Database File
Autogrow. This would give you at least a starting point to see what event
is the query stuck on. I would also download the blocker script from the
following KB article and run that to see if there is any blocking when the
query does not complete during the 10 min timeout interval.
271509 INF: How to Monitor SQL Server 2000 Blocking
http://support.microsoft.com/?id=271509
Thank you for using Microsoft newsgroups.
Sincerely
Pankaj Agarwal
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.sql

Job step failing with "ConnectionRead (WrapperRead())." error

We have a job step which executes a stored proc that fails intermittently
with this error:
Executed as user: domain\user. ConnectionRead (WrapperRead()). [SQLSTATE
01000] (Message 258) General network error. Check your network
documentation. [SQLSTATE 08S01] (Error 11). The step failed.
This stored proc executes just fine through QA.
Could it be that the SP does execute but that the step is being incorrectly
reported as failed?
Thank you
--
-- alan cranfield, DBAuse same ANSI settings in job like in QA
"Cranfield" wrote:
> We have a job step which executes a stored proc that fails intermittently
> with this error:
> Executed as user: domain\user. ConnectionRead (WrapperRead()). [SQLSTATE
> 01000] (Message 258) General network error. Check your network
> documentation. [SQLSTATE 08S01] (Error 11). The step failed.
> This stored proc executes just fine through QA.
> Could it be that the SP does execute but that the step is being incorrectly
> reported as failed?
> Thank you
> --
> -- alan cranfield, DBA|||I tried your suggestion. Job step still fails.
This must be a bug. I will raise a case with PSS.
thanks for the reply.
--
-- cranfield, DBA
"Aleksandar Grbic" wrote:
> use same ANSI settings in job like in QA
>
> "Cranfield" wrote:
> > We have a job step which executes a stored proc that fails intermittently
> > with this error:
> >
> > Executed as user: domain\user. ConnectionRead (WrapperRead()). [SQLSTATE
> > 01000] (Message 258) General network error. Check your network
> > documentation. [SQLSTATE 08S01] (Error 11). The step failed.
> >
> > This stored proc executes just fine through QA.
> >
> > Could it be that the SP does execute but that the step is being incorrectly
> > reported as failed?
> >
> > Thank you
> >
> > --
> > -- alan cranfield, DBA

JDBC Statement.executeBatch mysteriously and intermittently fails on good SQL statements

Hi Everyone,

I'm in the middle of adding support to our product for SQL 2005. It has been pretty simple except for one thing the jdbc Statement.executeBatch is mysteriously failing. I changed my error handling such that whenever part of a batch fails (EXECUTE_FAILED) the query gets re-run. Well, everytime I re-run the failed statment in a new new statement object using Statement.execute it works! Another characteristic of the failure is that no matter if the batch is running 1 or 10 updates in batch, they all fail with EXECUTE_FAILED and when re-run individually they each succeed. There is no exception thrown.

Has anyone run into this?

Netmon,

We have just fixed two Batch related bugs, the first one looks to be a similar issue to the problem you are describing. Would it be possible for you to test your scenario with our newly released June Community Tech Preview?

http://www.microsoft.com/downloads/details.aspx?familyid=f914793a-6fb4-475f-9537-b8fcb776befd&displaylang=en

For all of the issues resolved on this drop take a look at the release.txt change list that ships with the package, highlighting the batching issues here:

428197 Batch execution of prepared statements works correctly when there is more
than one item in the batch.

433394 Calling Statement.executeBatch after setting a BLOB value no longer throws
an SQLException with the message "The conversion from BLOB to BINARY is unsupported."