Objects related to DB: occasionally

Showing posts with label occasionally. Show all posts

Friday, March 30, 2012

ODBC error

Dear all,
We are using Ipswitch email application “ICS 2006’ with SQL 2000
enterprise edition as database. Occasionally web mail users are facing the
below
error on their web page.
‘ERROR [HY001][Microsoft][ODBC Microsoft Access Driver] Not enough space on
temporary disk. ERROR [IM006][Microsoft][ODBC Driver Manager] Driver’s
SQLSetConnectAttr failed ERROR [HY001][Microsoft][ODBC Microsoft Access
Driver] Not enough space on temporary disk.’
The problem gets rectified only after we restart the IIS service on the mail
server. What could be the reason for this problem? Kindly provide me with
your suggestions.
Regards
Ram
It's an error from MS Access - the cause depends on what you
are doing in Access, what version of Access, etc.
Try posting on one of the Access forums or newsgroups.
-Sue
On Sat, 17 Feb 2007 20:59:08 -0800, Ram
<Ram@.discussions.microsoft.com> wrote:

>Dear all,
> We are using Ipswitch email application ICS 2006 with SQL 2000
>enterprise edition as database. Occasionally web mail users are facing the
>below
>error on their web page.
> ERROR [HY001][Microsoft][ODBC Microsoft Access Driver] Not enough space on
>temporary disk. ERROR [IM006][Microsoft][ODBC Driver Manager] Drivers
>SQLSetConnectAttr failed ERROR [HY001][Microsoft][ODBC Microsoft Access
>Driver] Not enough space on temporary disk.
>The problem gets rectified only after we restart the IIS service on the mail
>server. What could be the reason for this problem? Kindly provide me with
>your suggestions.
>Regards
>Ram
>

ODBC error

Dear all,
We are using Ipswitch email application “ICS 2006’ with SQL 2000
enterprise edition as database. Occasionally web mail users are facing the
below
error on their web page.
‘ERROR [HY001][Microsoft][ODBC Microsoft Access Driver] Not en
ough space on
temporary disk. ERROR [IM006][Microsoft][ODBC Driver Manager] Dr
iver’s
SQLSetConnectAttr failed ERROR [HY001][Microsoft][ODBC Microsoft
Access
Driver] Not enough space on temporary disk.’
The problem gets rectified only after we restart the IIS service on the mail
server. What could be the reason for this problem? Kindly provide me with
your suggestions.
Regards
RamIt's an error from MS Access - the cause depends on what you
are doing in Access, what version of Access, etc.
Try posting on one of the Access forums or newsgroups.
-Sue
On Sat, 17 Feb 2007 20:59:08 -0800, Ram
<Ram@.discussions.microsoft.com> wrote:

>Dear all,
> We are using Ipswitch email application ICS 2006 with SQL 2000
>enterprise edition as database. Occasionally web mail users are facing the
>below
>error on their web page.
> ERROR [HY001][Microsoft][ODBC Microsoft Access Driver] Not en
ough space on
>temporary disk. ERROR [IM006][Microsoft][ODBC Driver Manager] D
rivers
>SQLSetConnectAttr failed ERROR [HY001][Microsoft][ODBC Microsof
t Access
>Driver] Not enough space on temporary disk.
>The problem gets rectified only after we restart the IIS service on the mai
l
>server. What could be the reason for this problem? Kindly provide me with
>your suggestions.
>Regards
>Ram
>sql

Wednesday, March 21, 2012

ODBC Connection failure

My application (written in a proprietary old 4GL) is connecting to a SQL 2000 database via ODBC

This works fine nearly all the time, but occasionally, it throws the following error when trying to connect :

Connection Failed

SQLState '01000'

SQL Server Error: 10060

[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]Connection Open(Connect()).

Connection Failed:

SQLState '08001'

SQL Server Error: 17

[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]SQL Server does not exist or access denied.

This error is displayed in a Windows dialog box. When the OK button on this dialog is clicked, it throws up a login/password box. When this is filled in and submitted, the connection is usually made cleanly and the application continues.

The big problem is that the application is an unattended service, and this dialog can go unnoticed for quite a while.

If these dialogs are 'Cancelled' rather than 'OK'd, the 4GL receives the error and arranges to re-try the connection itself.

Is ODBC responsible for popping up the interactive dialog, and, if so, can I do anything to force it to return an error instead ?

Hi Steve,

Interesting situation. The error 10060 means this: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. So you are probably experiencing a timeout in one of the socket-relation ops, most probably connect() (different from the SQL netlib's Connect() mentioned above).

The login popup is implemented by the SQL ODBC driver. You are probably using SQLDriverConnect in ODBC? It has a parameter "DriverCompletion", which could be:

SQL_DRIVER_PROMPT
SQL_DRIVER_COMPLETE
SQL_DRIVER_COMPLETE_REQUIRED
SQL_DRIVER_NOPROMPT

You probably have passed the first one (SQL_DRIVER_PROMPT). In order to make sure the SQLDriverConnect fails without popping up the troublesome dialog, you need to pass the SQL_DRIVER_NOPROMPT. I truly hope you are able to modify the 4GL application?

HTH,
Jivko Dobrev - MSFT
--
This posting is provided "AS IS" with no warranties, and confers no rights.

|||

Thanks a lot Jivko.

Unfortunately, the only parameter the 4GL allows me to specify is the DSN name.

I'll be on to the vendor's support desk rather forcefully first thing on Monday morning - thanks for the Ammo!

Friday, March 9, 2012

Occasionally slow to connect to a sql2005 database

We have a VB app talking to SQL 2000 and SQL2005 databases. Most of our clients use SQL2000, but the new ones we are deploying with SQL2005

Sometimes the app is slow in establishing a connection to the database when it is SQL2005. The provider is sqloledb. We never get this delay in SQL2000. Sometimes it takes seconds to establish a connection - this is even the case when the app is on the same machine as the database.

We are using SQL authentication - always with the same connect string.

Any ideas ?

thanks
Bruce

Any chance of a reply on this one ?

Thanks

Bruce

|||

I have the same problem, Win32::SqlServer perl-module to connect to MS Sql Server 2005 in some cgi-scripts.

They run on the same server as the DBMS.

It must be related to the authentication method -- it is slow when the username/password is set explicitly and hence SQL authentication is forced.

If I run the scripts manually with Integrated Security (default) it connects in no time (give or take a few microsec.). Unfortunately this is not possible when run through IIS which I guess is because it doesn′t have the required permissions.

So... is it possible to give permission on a file-basis (in this case a cgi-script) so that an IIS-initiated process can access MS Sql Server with integrated seciruty?

This may not be the solution to original posters problem but it might give a hint in the right direction.

|||Same here, VB app connects to SQL Express using SQL Authentication. Using an identical connection string each time I get intermittent occurence of this slow/not responding symptoms.

It can sit and wait for a simple query to execute for maybe 30 secs or more in many cases. I had thought the Visual Studio Process had been hogging resources but this has now occured in our release builds (But not as often). This problem is replicated across our development machines.

AutoClose is set to False
AutoShrink is set to False

The query has only failed to execute on one occasion, unfortunately on a customers machine where presumably the query had timed-out. In most other cases the query has executed fine but after an impossibly long wait.

Is the server idling? If so how can I best test for the idle condition or alter the parameters for idle condition.

Cheers
R

Occasionally slow to connect to a sql2005 database

We have a VB app talking to SQL 2000 and SQL2005 databases. Most of our clients use SQL2000, but the new ones we are deploying with SQL2005

We are using SQL authentication - always with the same connect string.

Any ideas ?

thanks
Bruce

Any chance of a reply on this one ?

Thanks

Bruce

|||

I have the same problem, Win32::SqlServer perl-module to connect to MS Sql Server 2005 in some cgi-scripts.

They run on the same server as the DBMS.

It must be related to the authentication method -- it is slow when the username/password is set explicitly and hence SQL authentication is forced.

So... is it possible to give permission on a file-basis (in this case a cgi-script) so that an IIS-initiated process can access MS Sql Server with integrated seciruty?

This may not be the solution to original posters problem but it might give a hint in the right direction.

|||Same here, VB app connects to SQL Express using SQL Authentication. Using an identical connection string each time I get intermittent occurence of this slow/not responding symptoms.

AutoClose is set to False
AutoShrink is set to False

Is the server idling? If so how can I best test for the idle condition or alter the parameters for idle condition.

Cheers
R

Occasionally slow to connect to a sql2005 database

We have a VB app talking to SQL 2000 and SQL2005 databases. Most of our clients use SQL2000, but the new ones we are deploying with SQL2005

We are using SQL authentication - always with the same connect string.

Any ideas ?

thanks
Bruce

Any chance of a reply on this one ?

Thanks

Bruce

|||

I have the same problem, Win32::SqlServer perl-module to connect to MS Sql Server 2005 in some cgi-scripts.

They run on the same server as the DBMS.

It must be related to the authentication method -- it is slow when the username/password is set explicitly and hence SQL authentication is forced.

So... is it possible to give permission on a file-basis (in this case a cgi-script) so that an IIS-initiated process can access MS Sql Server with integrated seciruty?

This may not be the solution to original posters problem but it might give a hint in the right direction.

|||Same here, VB app connects to SQL Express using SQL Authentication. Using an identical connection string each time I get intermittent occurence of this slow/not responding symptoms.

AutoClose is set to False
AutoShrink is set to False

Is the server idling? If so how can I best test for the idle condition or alter the parameters for idle condition.

Cheers
R

Occasionally slow to connect to a sql2005 database

We have a VB app talking to SQL 2000 and SQL2005 databases. Most of our clients use SQL2000, but the new ones we are deploying with SQL2005

We are using SQL authentication - always with the same connect string.

Any ideas ?

thanks
Bruce

Any chance of a reply on this one ?

Thanks

Bruce

|||

I have the same problem, Win32::SqlServer perl-module to connect to MS Sql Server 2005 in some cgi-scripts.

They run on the same server as the DBMS.

It must be related to the authentication method -- it is slow when the username/password is set explicitly and hence SQL authentication is forced.

So... is it possible to give permission on a file-basis (in this case a cgi-script) so that an IIS-initiated process can access MS Sql Server with integrated seciruty?

This may not be the solution to original posters problem but it might give a hint in the right direction.

|||Same here, VB app connects to SQL Express using SQL Authentication. Using an identical connection string each time I get intermittent occurence of this slow/not responding symptoms.

AutoClose is set to False
AutoShrink is set to False

Is the server idling? If so how can I best test for the idle condition or alter the parameters for idle condition.

Cheers
R

Occasional Error When Executing CLR Stored Procedure

This CLR stored procedure executes without fail 99% of the time. However, occasionally it will fail with the following error:

A .NET Framework error occurred during execution of user-defined routine or aggregate "Run_SRS_Report": System.Exception: Attempt to perform native server operation (AllocateNativeRequest) outside of its valid scope.

Below is the section of code that fails:

<code>

Private Shared Sub GetReportParameters()
Dim drReportParameters As SqlDataReader

Try
' set the parameters for the command request.
_SQLCommandRequest = _SQLConnection.CreateCommand()

_SQLCommandRequest.CommandText = _spReportParms

_SQLCommandRequest.CommandType = CommandType.StoredProcedure

' get the information for the data reader request.
drReportParameters = _SQLCommandRequest.ExecuteReader

' make sure that we have something first.
If Not drReportParameters Is Nothing Then

' find out if we have any rows returned.
If drReportParameters.HasRows Then

' read each of the rows looking for the respective value.
While drReportParameters.Read

' make sure that we can get the appropriate code id.
If (Not IsDBNull(drReportParameters.Item("Code_ID"))) AndAlso (Not IsDBNull(drReportParameters.Item("Display_Text"))) Then

' set the parameters for each of the following internal variables.
Select Case drReportParameters.Item("Code_ID").ToString
Case Is = "PDFP Path"
_FileLocationPDFP = drReportParameters.Item("Display_Text").ToString
Case Is = "PDF Temp Path"
_FileLocationPDFTemp = drReportParameters.Item("Display_Text").ToString
Case Is = "LogFile Path"
'''_SqlPipe.Send("Path from sys codes: " & drReportParameters.Item("Display_Text").ToString)
_FileLocationLogFile = Path.Combine(drReportParameters.Item("Display_Text").ToString, "SRSReportLog_" & Now.ToString("HHmmss") & ".txt")
Case Is = "LogFile Flag"
_swLogFlag = IIf(drReportParameters.Item("Display_Text").ToString = "False", False, True)
Case Is = "Delete PDF"
_DeletePDFFlag = IIf(drReportParameters.Item("Display_Text").ToString = "False", False, True)
Case Is = "PrintTool"
_PrintTool = drReportParameters.Item("Display_Text").ToString
Case Is = "BPP Path"
_BppPath = drReportParameters.Item("CharVar1").ToString
Case Is = "SendToPrinter"
_SendToPrinterFlag = IIf(drReportParameters.Item("Display_Text").ToString = "False", False, True)
Case Else
' ignore it.
End Select

End If

End While

End If

Catch ex As Exception
' throw a new exception to trip up the PrintReport() function.
Throw New Exception(ex.Message)

Finally

' make sure that we close out the datareader, regardless.
If Not drReportParameters Is Nothing Then
If Not drReportParameters.IsClosed Then drReportParameters.Close()
End If

End Try

End Sub

</code>

Any ideas why this would fail only occasionally (maybe 1% of the time it's executed)?

_SQLCommandRequest is a shared (that is, static) variable, right? You are seeing this error because your proceduce is being executed on multiple threads at the same time, and multiple threads are not allowed to use the same SqlConnection at the same time. (The error message is fixed in the next version of SQL Server to be more clear what the problem is).

It looks like you frequently use static variables within your SP, so even if you fix this problem by using a local, non-shared SqlCommand object, you will run into other problems due to multiple threads accessing the same shared state.

Steven
|||

Understood. Thanks for the explanation.

So all I have to do is make everything local, non-shared then right?

Except for the main sub procedure declaration below which has to remain shared right?:

<Microsoft.SqlServer.Server.SqlProcedure()> _
Public Shared Sub Run_SRS_Report(ByVal ip_URL As String _

Am I on the right track?

|||

Yes, everything should be a local or class instance field, unless it is a constant, readonly value. Ideally, you should try to deploy the assembly under SAFE or EXTERNAL_ACCESS permission set, which disallows the use of static variables to prevent this type of problem.

|||

Thanks Steven. I've changed everything up so there are no static variables and re-deployed. Hopefully that will fix the problem. If not I'll post again.

Occasional Error When Executing CLR Stored Procedure

This CLR stored procedure executes without fail 99% of the time. However, occasionally it will fail with the following error:

A .NET Framework error occurred during execution of user-defined routine or aggregate "Run_SRS_Report": System.Exception: Attempt to perform native server operation (AllocateNativeRequest) outside of its valid scope.

Below is the section of code that fails:

<code>

Private Shared Sub GetReportParameters()
Dim drReportParameters As SqlDataReader

Try
' set the parameters for the command request.
_SQLCommandRequest = _SQLConnection.CreateCommand()

_SQLCommandRequest.CommandText = _spReportParms

_SQLCommandRequest.CommandType = CommandType.StoredProcedure

' get the information for the data reader request.
drReportParameters = _SQLCommandRequest.ExecuteReader

' make sure that we have something first.
If Not drReportParameters Is Nothing Then

' find out if we have any rows returned.
If drReportParameters.HasRows Then

' read each of the rows looking for the respective value.
While drReportParameters.Read

' make sure that we can get the appropriate code id.
If (Not IsDBNull(drReportParameters.Item("Code_ID"))) AndAlso (Not IsDBNull(drReportParameters.Item("Display_Text"))) Then

End If

End While

End If

Catch ex As Exception
' throw a new exception to trip up the PrintReport() function.
Throw New Exception(ex.Message)

Finally

' make sure that we close out the datareader, regardless.
If Not drReportParameters Is Nothing Then
If Not drReportParameters.IsClosed Then drReportParameters.Close()
End If

End Try

End Sub

</code>

Any ideas why this would fail only occasionally (maybe 1% of the time it's executed)?

Steven
|||

Understood. Thanks for the explanation.

So all I have to do is make everything local, non-shared then right?

Except for the main sub procedure declaration below which has to remain shared right?:

<Microsoft.SqlServer.Server.SqlProcedure()> _
Public Shared Sub Run_SRS_Report(ByVal ip_URL As String _

Am I on the right track?

|||

Thanks Steven. I've changed everything up so there are no static variables and re-deployed. Hopefully that will fix the problem. If not I'll post again.

Occasional delay in processing incoming packets

I have a problem where occasionally (less that 1%) a packet is not
processed for as long as 25 seconds.
1) I get the exact same behavior with ADO 2.8 and ADO.NET.
2) A detailed view of the chain of events looks like this:
? T+0 seconds ? connection from the pool is allocated
? T+0 seconds ? vb call to Command.Execute (or c# call to
DataAdapter.Fill)
? T+0 seconds ? single packet (118 bytes) is sent to database machine
(from a web server)
? T+0.1 seconds ? ack received from database machine indicating packet
was successfully received in full
? T+25 seconds ? SQL Profiler trace "Start Time" for database call
? T+25 seconds ? SQL Profiler trace "End Time" for database call
? T+25 seconds ? data returns to application
? T+25 seconds ? connection is returned to the pool
So the "lost time" occurs on the database machine between the time the
packet is received, and the time Profiler claims SQL Server started
working on the query.
I've tried to run perfmon on the obvious counters on the database but
I've failed to find anything out of the ordinary. There are so many
counters! Any ideas on what specifically I should be looking at now?
~ James
Occasional delay in processing incoming packetsJames wrote:
> I have a problem where occasionally (less that 1%) a packet is not
> processed for as long as 25 seconds.
> 1) I get the exact same behavior with ADO 2.8 and ADO.NET.
> 2) A detailed view of the chain of events looks like this:
> . T+0 seconds - connection from the pool is allocated
> . T+0 seconds - vb call to Command.Execute (or c# call to
> DataAdapter.Fill)
> . T+0 seconds - single packet (118 bytes) is sent to database machine
> (from a web server)
> . T+0.1 seconds - ack received from database machine indicating packet
> was successfully received in full
> . T+25 seconds - SQL Profiler trace "Start Time" for database call
> . T+25 seconds - SQL Profiler trace "End Time" for database call
> . T+25 seconds - data returns to application
> . T+25 seconds - connection is returned to the pool
>
> So the "lost time" occurs on the database machine between the time the
> packet is received, and the time Profiler claims SQL Server started
> working on the query.
> I've tried to run perfmon on the obvious counters on the database but
> I've failed to find anything out of the ordinary. There are so many
> counters! Any ideas on what specifically I should be looking at now?
> ~ James
> Occasional delay in processing incoming packets
If you can, try setting up an alias to teh SQL Server machine using a
different network protocol (e.g. named pipes instead of TCP/IP). That
way you can see if the problem is related to the network library. If the
start time in Profiler is T+25, it sounds like SQL Server is not getting
the packet until T+25.
You can set up aliases from the SQL Server Client Tools - Client Network
Utility.
David G.|||I created a Named Pipes alias and used that instead of TCP/IP. I've
never done that before, so I checked to make sure the connections were
using Named Pipes before continuing.
During this test I still have the same problem.
"David G." <david_nospam@.nospam.com> wrote in message news:<eOaWzPOhEHA.1276@.TK2MSFTNGP09.phx.gbl>...
> James wrote:
> > I have a problem where occasionally (less that 1%) a packet is not
> > processed for as long as 25 seconds.
> >
> > 1) I get the exact same behavior with ADO 2.8 and ADO.NET.
> >
> > 2) A detailed view of the chain of events looks like this:
> >
> > . T+0 seconds - connection from the pool is allocated
> > . T+0 seconds - vb call to Command.Execute (or c# call to
> > DataAdapter.Fill)
> > . T+0 seconds - single packet (118 bytes) is sent to database machine
> > (from a web server)
> > . T+0.1 seconds - ack received from database machine indicating packet
> > was successfully received in full
> > . T+25 seconds - SQL Profiler trace "Start Time" for database call
> > . T+25 seconds - SQL Profiler trace "End Time" for database call
> > . T+25 seconds - data returns to application
> > . T+25 seconds - connection is returned to the pool
> >
> >
> > So the "lost time" occurs on the database machine between the time the
> > packet is received, and the time Profiler claims SQL Server started
> > working on the query.
> >
> > I've tried to run perfmon on the obvious counters on the database but
> > I've failed to find anything out of the ordinary. There are so many
> > counters! Any ideas on what specifically I should be looking at now?
> >
> > ~ James
> >
> > Occasional delay in processing incoming packets
> If you can, try setting up an alias to teh SQL Server machine using a
> different network protocol (e.g. named pipes instead of TCP/IP). That
> way you can see if the problem is related to the network library. If the
> start time in Profiler is T+25, it sounds like SQL Server is not getting
> the packet until T+25.
> You can set up aliases from the SQL Server Client Tools - Client Network
> Utility.|||James wrote:
> I created a Named Pipes alias and used that instead of TCP/IP. I've
> never done that before, so I checked to make sure the connections were
> using Named Pipes before continuing.
> During this test I still have the same problem.
> "David G." <david_nospam@.nospam.com> wrote in message
> news:<eOaWzPOhEHA.1276@.TK2MSFTNGP09.phx.gbl>...
>> James wrote:
>> I have a problem where occasionally (less that 1%) a packet is not
>> processed for as long as 25 seconds.
>> 1) I get the exact same behavior with ADO 2.8 and ADO.NET.
>> 2) A detailed view of the chain of events looks like this:
>> . T+0 seconds - connection from the pool is allocated
>> . T+0 seconds - vb call to Command.Execute (or c# call to
>> DataAdapter.Fill)
>> . T+0 seconds - single packet (118 bytes) is sent to database
>> machine (from a web server)
>> . T+0.1 seconds - ack received from database machine indicating
>> packet was successfully received in full
>> . T+25 seconds - SQL Profiler trace "Start Time" for database call
>> . T+25 seconds - SQL Profiler trace "End Time" for database call
>> . T+25 seconds - data returns to application
>> . T+25 seconds - connection is returned to the pool
>>
>> So the "lost time" occurs on the database machine between the time
>> the packet is received, and the time Profiler claims SQL Server
>> started working on the query.
>> I've tried to run perfmon on the obvious counters on the database
>> but I've failed to find anything out of the ordinary. There are so
>> many counters! Any ideas on what specifically I should be looking
>> at now?
>> ~ James
>> Occasional delay in processing incoming packets
>> If you can, try setting up an alias to teh SQL Server machine using a
>> different network protocol (e.g. named pipes instead of TCP/IP). That
>> way you can see if the problem is related to the network library. If
>> the start time in Profiler is T+25, it sounds like SQL Server is not
>> getting the packet until T+25.
>> You can set up aliases from the SQL Server Client Tools - Client
>> Network Utility.
Is this occurring from only one client or from all clients? What SP are
you running on SQL Server?
--
David G.|||There are 11 web servers and they all exhibit the same behavior.
At first I thought the times of the occurrences on the different web
servers did not correlate ? but now I think they do. Previously I was
only tracking delays of 5 seconds or greater. I think if I track all
delays I may get more matches.
I also tried tracing everything that was executing on the server ? I
did that for 6 minutes and I had one delay of 6 seconds on one web
server to compare. Then I looked for things that started at the same
time that my delayed sp was supposed to start? and I found only two
items ? which is very strange because this is a busy database. So I
grouped the results of the trace by StartTime per second yielding 360
numbers . The normal parts of the graph bounce around between 200 and
600 (not including full text calls) ? and for the second that I
submitted the delayed sp, the number plummets to 2. Full text calls
plummet to 0, and EndTimes for this second are 0 also. This was
followed by a peak of 860 (non-ft StartTimes) 7 seconds later. I do
not know if this happens every time ? I have more testing to do.
I wish I had somewhere I could post the data for DL but I do not right
now.
Anyone know what the capacity of SQL server is for incoming sql
requests? It averaged 895/second (including fulltext index calls to
sp_fulltext_getdata) with a peak of 1549 during this 6 minutes.
>> What SP are you running on SQL Server?
Service Pack?
SQL Server Machine:
Windows Server 2003 Enterprise (NT 5.2 (3790))
Quad Xeon 3.06GHz, 4GB RAM
SQL Server Enterprise 8.00.818 (SP3)
Stored Procedure?
The stored procedure I targeted just does a single row select on a
small table using the PK. I haven't gone to this level of detail on
any other sp, but I assume the problem can affect any call to the db.
~ James
"David G." <david_nospam@.nospam.com> wrote in message news:<eDkzArfhEHA.3912@.TK2MSFTNGP11.phx.gbl>...
> James wrote:
> > I created a Named Pipes alias and used that instead of TCP/IP. I've
> > never done that before, so I checked to make sure the connections were
> > using Named Pipes before continuing.
> >
> > During this test I still have the same problem.
> >
> > "David G." <david_nospam@.nospam.com> wrote in message
> > news:<eOaWzPOhEHA.1276@.TK2MSFTNGP09.phx.gbl>...
> >> James wrote:
> >> I have a problem where occasionally (less that 1%) a packet is not
> >> processed for as long as 25 seconds.
> >>
> >> 1) I get the exact same behavior with ADO 2.8 and ADO.NET.
> >>
> >> 2) A detailed view of the chain of events looks like this:
> >>
> >> . T+0 seconds - connection from the pool is allocated
> >> . T+0 seconds - vb call to Command.Execute (or c# call to
> >> DataAdapter.Fill)
> >> . T+0 seconds - single packet (118 bytes) is sent to database
> >> machine (from a web server)
> >> . T+0.1 seconds - ack received from database machine indicating
> >> packet was successfully received in full
> >> . T+25 seconds - SQL Profiler trace "Start Time" for database call
> >> . T+25 seconds - SQL Profiler trace "End Time" for database call
> >> . T+25 seconds - data returns to application
> >> . T+25 seconds - connection is returned to the pool
> >>
> >>
> >> So the "lost time" occurs on the database machine between the time
> >> the packet is received, and the time Profiler claims SQL Server
> >> started working on the query.
> >>
> >> I've tried to run perfmon on the obvious counters on the database
> >> but I've failed to find anything out of the ordinary. There are so
> >> many counters! Any ideas on what specifically I should be looking
> >> at now?
> >>
> >> ~ James
> >>
> >> Occasional delay in processing incoming packets
> >>
> >> If you can, try setting up an alias to teh SQL Server machine using a
> >> different network protocol (e.g. named pipes instead of TCP/IP). That
> >> way you can see if the problem is related to the network library. If
> >> the start time in Profiler is T+25, it sounds like SQL Server is not
> >> getting the packet until T+25.
> >>
> >> You can set up aliases from the SQL Server Client Tools - Client
> >> Network Utility.
> Is this occurring from only one client or from all clients? What SP are
> you running on SQL Server?

Friday, March 30, 2012

ODBC error

ODBC error

Wednesday, March 21, 2012

ODBC Connection failure

Friday, March 9, 2012

Occasionally slow to connect to a sql2005 database

Occasionally slow to connect to a sql2005 database

Occasionally slow to connect to a sql2005 database

Occasionally slow to connect to a sql2005 database

Occasional Error When Executing CLR Stored Procedure

Occasional Error When Executing CLR Stored Procedure

Occasional delay in processing incoming packets

Occasional delay in processing incoming packets

Occasional delay in processing incoming packets

Objects related to DB

Blog Archive

About Me