(ODBC driver) timeout expired when query "DELETE FROM mytable"

Hi,

I'm running SQL server 2000. I have at table with about 12 million records.

I want to empty the table. I use the Query option from Tables/mytable/opentable/query.

I type in the query and select Run. The process runs for some time, then raises

an error box as follows: (title)SQL Server Enterprise Manager. The body text says:

[Microsoft][ODBC SQL Server Driver] Timeout Expired. I've tried every timeout

setting I can find. I've tried setting all timeouts to 0 (infinite) to no avail.

Please help.........

Note: I can get the table empty if I select TOP n records, then DELETE FROM but

that takes forever!! It is also not a process that's very amenable to a clean programatic

solution.

Thanks, jack

That's very strange. Setting timeout to '0' should do the trick.

If all you need to do is empty the table you could just call "truncate table table_name". That should run pretty quickly.

Sorry you're having issues. Please reactivate this thread if the 'truncate' command doesn't fix your issue.

~Warren

|||

Warren,

Thanks!

I have changed the query to "Truncate Table" and it's much faster. I haven't

tried it with the large table yet -- I'll have to reload the data before I know for

sure. I used the "Delete" command only because I hadn't stumbled on the "Truncate"

command. I still would like to know why I'm getting the timeout since I'm sure it will

jump up and bite me later because I'm dealing with such large tables, and Murphy is

looking over my shoulder -- ha!

jack

|||Consider that when you execute DELETE, the operation is logged so you are essentially "moving" the deleted rows to the transaction log with all of the associated disk IO expenses. Truncate table is also logged, but simply tells SQL Server to "drop" the data and leave the schema--it's dramatically simpler and faster.|||

William,

"Dramatically" is an understatement! I'm amazed at how quickly the table is

emptied using "Truncate". Although knowing why, it makes perfect sense. Thanks

for the expanation of the 'why', that's even more valuable than the 'how'. Is there an

explicit means of preventing the transaction logging - since it's so time costly? Is

there a downside to such a thing if it exists?

I'm still bewildered about the "timeout expired" error inspired by the length of time

the DELETE takes. I guess I'll have to pull my copy of the "Guide to..." off the shelf

and review ADO/ODBC query timeouts etc.

thanks, jack

|||

No, you can't (and should not) "turn off" the transaction log--it's your safety net. Yes, there are other operations that can be executed without the log getting in the way (like BulkCopy).

Consider that the Delete command must also delete the Index(es) for each row as well as reallocate space and execute other operations that take CPU time, RAM and disk IO. While the Truncate is fast, it also means that the server can clean up the freed space when it has idle time and it needs the space. For long operations you can set the CommandTimeout to a higher number, but whenever I find a neeed to do this I look for a more efficient way to handle the task...

hth

|||

William,

Thanks! I'm in good shape now.

jack

"The statement did not return a result set" error on SPs with exec

I'm trying to modify our application to use the SQL Server 2005 JDBC driver. After making the appropriate changes most stuff seems to work OK, except for any stored procedures that contain an exec statement and return a result set. When the stored procedure is called with executeQuery it throws a SQLServerException with the error "The statement did not return a result set". Other query SPs that don't have an exec work just fine. It doesn't matter if the exec is calling another SP, or if it's executing a constructed SQL string. Also, this worked OK with the DataDirect JDBC drivers that we used to use. I'm running this on Windows XP with SQL Server 2000.

Hi Richard,

Could you post a sample stored procedure that demonstrates this behavior and the syntax you are using to call it? It sounds like the driver thinks the stored procedure is returning an update count rather than a result set as the first result.

Thanks,

--David Olix

JDBC Development

|||

This took a while to pinpoint. It turns out that the problem doesn't have anything to do with exec, instead it looks like a problem with UpdateText. I can reproduce the problem with the following sp:

create procedure spTest
@.id_list ntext
as
declare @.txtptr binary(16),
@.list_length integer

Create Table #parse
( IDList ntext )

Insert Into #parse
Select @.id_list

Select @.txtptr = TextPtr(IDList)
from #parse with (nolock)

Select @.list_length = DataLength(@.id_list)
if ( @.list_length > 0 AND Substring(@.id_list,@.list_length,1) <> ',')
Begin
UpdateText #parse.IDList @.txtptr NULL 0 ','
End
select * from #parse -- comment out this line to have no result set

Return 0

GO

and call it with the following:

PreparedStatement stmt = null;
ResultSet rs = null;
try {
Connection con = this.getConnection();
stmt = con.prepareCall("{call spTest(?)}");
stmt.setString(1, "12,15");
rs = stmt.executeQuery();
}
catch( SQLException e )
{
logger.severe(e.getMessage());
e.printStackTrace();
}
finally {
closeVars(null,stmt,rs);
}

If I replace the "UpdateText" with anything else, no exception is thrown.

|||

I'm wondering if UpdateText is returning a value that the driver interprets as an update count. Could you try calling this sp with execute() rather than executeQuery() and let me know if you get an update count followed by the result set that you expect?

Thanks again,

--David Olix

JDBC Development

|||If I call execute followed by getUpdateCount, it returns 1 for the update count. If I call getResultSet after that, it returns null.|||

I forgot to mention it above, but you need to call getMoreResults between getUpdateCount and getResultSet. I think the result set should be there.

Regardless, this gives me enough information to start on a fix to your problem. You may want to file this as a bug through the MSDN Product Feedback Center http://lab.msdn.microsoft.com/productfeedback/default.aspx so that you can track it.

Thanks!

|||

Even after I added a getMoreResults call between getUpdateCount and getResultSet, getResultSet still returned a null ResultSet.

I'll file a bug report. Thanks for your help.

"The statement did not return a result set" error on SPs with exec

I'm trying to modify our application to use the SQL Server 2005 JDBC driver. After making the appropriate changes most stuff seems to work OK, except for any stored procedures that contain an exec statement and return a result set. When the stored procedure is called with executeQuery it throws a SQLServerException with the error "The statement did not return a result set". Other query SPs that don't have an exec work just fine. It doesn't matter if the exec is calling another SP, or if it's executing a constructed SQL string. Also, this worked OK with the DataDirect JDBC drivers that we used to use. I'm running this on Windows XP with SQL Server 2000.

Hi Richard,

Could you post a sample stored procedure that demonstrates this behavior and the syntax you are using to call it? It sounds like the driver thinks the stored procedure is returning an update count rather than a result set as the first result.

Thanks,

--David Olix

JDBC Development

|||

This took a while to pinpoint. It turns out that the problem doesn't have anything to do with exec, instead it looks like a problem with UpdateText. I can reproduce the problem with the following sp:

create procedure spTest
@.id_list ntext
as
declare @.txtptr binary(16),
@.list_length integer

Create Table #parse
( IDList ntext )

Insert Into #parse
Select @.id_list

Select @.txtptr = TextPtr(IDList)
from #parse with (nolock)

Select @.list_length = DataLength(@.id_list)
if ( @.list_length > 0 AND Substring(@.id_list,@.list_length,1) <> ',')
Begin
UpdateText #parse.IDList @.txtptr NULL 0 ','
End
select * from #parse -- comment out this line to have no result set

Return 0

GO

and call it with the following:

PreparedStatement stmt = null;
ResultSet rs = null;
try {
Connection con = this.getConnection();
stmt = con.prepareCall("{call spTest(?)}");
stmt.setString(1, "12,15");
rs = stmt.executeQuery();
}
catch( SQLException e )
{
logger.severe(e.getMessage());
e.printStackTrace();
}
finally {
closeVars(null,stmt,rs);
}

If I replace the "UpdateText" with anything else, no exception is thrown.

|||

I'm wondering if UpdateText is returning a value that the driver interprets as an update count. Could you try calling this sp with execute() rather than executeQuery() and let me know if you get an update count followed by the result set that you expect?

Thanks again,

--David Olix

JDBC Development

|||If I call execute followed by getUpdateCount, it returns 1 for the update count. If I call getResultSet after that, it returns null.|||

I forgot to mention it above, but you need to call getMoreResults between getUpdateCount and getResultSet. I think the result set should be there.

Regardless, this gives me enough information to start on a fix to your problem. You may want to file this as a bug through the MSDN Product Feedback Center http://lab.msdn.microsoft.com/productfeedback/default.aspx so that you can track it.

Thanks!

|||

Even after I added a getMoreResults call between getUpdateCount and getResultSet, getResultSet still returned a null ResultSet.

I'll file a bug report. Thanks for your help.

"Execute on main package thread" (dts2000) still available on ssis ?

Hello

The Navision 4.0 ODBC-driver gives following error when connecting in ssis :
"Internal error 182 in module 1."
The driver doesn't like multi-threading behavior . In DTS2000, this issue could be solved by turning on the workflow-option "Execute on main package thread" !
I was wondering... is there a way to do this also in SSIS ?

Kind regards

Geert G.Interesting issue, for which I have no sure answer. Looking at the properties we have you may like to try the MaxConcurrentExecutables property at the package level, and the EngineThreads property for the Data Flow. These would I assume limit you to one thread, but if that is the main one, I have no idea.|||

Thank you for your reply

Unfortunately when I try to change the 'EngineThreads' to 1, following error occurs:
"Could not set the property value: Error at Data Flow Task [DTS.Pipeline]: The EngineThreads property of the Data Flow task must be between 2 and 60. An attempt was made to set the property to a value that is too small."

Even changing MaxConcurrentExecutables to 1 or 0 doesn't solve the problem

|||Sorry I didn't test this. Better ask someone who knows what they are talking about. Product Team over to you....