A transport-level error has occurred when sending the request to the server

Hi all,

I am new to SQL 2005. I have one issue and it is as follows:

I write a simple query and run it; it works fine.

Now I break the network connection and run the query; in this case it runs fine.

But when I reconnect the network and run the query, then I get an error as follows:

"A transport-level error has occurred when sending the request to the server. (provider: Named Pipes Provider, error: 0 - An unexpected network error occurred.) "

Every thing is local here. So how the network issue comes here?

For some reason the connection was made through Named Pipes instead of Shared Memory (the default for local connections), which suggests that SqlClient did not recognize the connection was local, and most likely tunneled Named Pipes over TCP, hence, disocnnecting the network has impact.

How do you specify the server name - perhaps by its fully qualified domain name (FQDN), or IP address?

If you specify it by the hostname or "." or "(local)" SqlClient should recognize the local connection, and you should not see the error.

|||

Hi ,

sorry to reply late.

I tried the above mentioned case. In case of "." or "(local)" it did not connect to the SQL server. When I try it by the host name then same original problem persist.

Thanks

|||

Well sorry once again!!!

I made some mistake in the above reply.

I tried as mentioned in the solution and here are the results:

In case of "." it works fine

In case of host name the problem still persists.

for "(local)" I have not yet tested.

Thanks

|||

Regarding the host name problem - do you specify the server name exactly the same way as returned by the Windows hostname command-line command?

|||

Yes, I specify the server name exactly as returned by the the windows hostname command-line command. But the problem still persists.

|||

Great post ~ I had the same problem.

When trying to connect to a local SQL Server I was using 'localhost', which resulted in "A transport-level error has occurred...".

To resolve, I replaced 'localhost' with '(local)', as suggested.

Regards.

|||I same the same problem but I am connecting to remote server using IP, any idea?

A transport-level error has occurred when sending the request to the server

Hi all,

I am new to SQL 2005. I have one issue and it is as follows:

I write a simple query and run it; it works fine.

Now I break the network connection and run the query; in this case it runs fine.

But when I reconnect the network and run the query, then I get an error as follows:

"A transport-level error has occurred when sending the request to the server. (provider: Named Pipes Provider, error: 0 - An unexpected network error occurred.) "

Every thing is local here. So how the network issue comes here?

For some reason the connection was made through Named Pipes instead of Shared Memory (the default for local connections), which suggests that SqlClient did not recognize the connection was local, and most likely tunneled Named Pipes over TCP, hence, disocnnecting the network has impact.

How do you specify the server name - perhaps by its fully qualified domain name (FQDN), or IP address?

If you specify it by the hostname or "." or "(local)" SqlClient should recognize the local connection, and you should not see the error.

|||

Hi ,

sorry to reply late.

I tried the above mentioned case. In case of "." or "(local)" it did not connect to the SQL server. When I try it by the host name then same original problem persist.

Thanks

|||

Well sorry once again!!!

I made some mistake in the above reply.

I tried as mentioned in the solution and here are the results:

In case of "." it works fine

In case of host name the problem still persists.

for "(local)" I have not yet tested.

Thanks

|||

Regarding the host name problem - do you specify the server name exactly the same way as returned by the Windows hostname command-line command?

|||

Yes, I specify the server name exactly as returned by the the windows hostname command-line command. But the problem still persists.

|||

Great post ~ I had the same problem.

When trying to connect to a local SQL Server I was using 'localhost', which resulted in "A transport-level error has occurred...".

To resolve, I replaced 'localhost' with '(local)', as suggested.

Regards.

|||I same the same problem but I am connecting to remote server using IP, any idea?

A serious bug in SQL-2005/2008 Replication: Loosing @@IDENTITY value

Hello all!

There is a bug in SQL-2005/2008 Replication system, which may break data integrity, when using @.@.IDENTITY function to update FOREIGN KEY of some table.

When Merge replication is set up, and there is a table article with IDENTITY column in it, after inserting a new row in the table a value of @.@.IDENTITY function does not actually shows just inserted row's identity value.

This issue also generated when performing inserts via ADO.

For details, see my Feedback to Microsoft:

https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=286165

Also, there are other comments on this problem:

http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.data.ado&tid=dcb56477-15fe-413e-a90a-3e1816bc7375&p=1

https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=281682

https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=284124

SQL Server Katmai July CTP has been released. But the bug described above is not resolved there. It still can be generated the same way! However, the feedback is marked as "Resolved"...

|||

it looks like it was resolved as by design. do you have any of the feedback or reasons this was marked by design?

|||

You should not rely on @.@.identity and propgram your solution.

You should rather look at using scope_identity.

|||

Thanks, Greg and Mahesh!

Now I understand, why it market as "Resolved by Design". But there is another problem: ADO itself uses @.@.IDENTITY instead of SCOPE_IDENTITY when inserts a value to a table. So, it seems impossible to use SQL-clients based on ADO in Merge Replication!

A serious bug in SQL-2005/2008 Replication: Loosing @@IDENTITY value

Hello all!

There is a bug in SQL-2005/2008 Replication system, which may break data integrity, when using @.@.IDENTITY function to update FOREIGN KEY of some table.

When Merge replication is set up, and there is a table article with IDENTITY column in it, after inserting a new row in the table a value of @.@.IDENTITY function does not actually shows just inserted row's identity value.

This issue also generated when performing inserts via ADO.

For details, see my Feedback to Microsoft:

https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=286165

Also, there are other comments on this problem:

http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.data.ado&tid=dcb56477-15fe-413e-a90a-3e1816bc7375&p=1

https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=281682

https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=284124

SQL Server Katmai July CTP has been released. But the bug described above is not resolved there. It still can be generated the same way! However, the feedback is marked as "Resolved"...

|||

it looks like it was resolved as by design. do you have any of the feedback or reasons this was marked by design?

|||

You should not rely on @.@.identity and propgram your solution.

You should rather look at using scope_identity.

|||

Thanks, Greg and Mahesh!

Now I understand, why it market as "Resolved by Design". But there is another problem: ADO itself uses @.@.IDENTITY instead of SCOPE_IDENTITY when inserts a value to a table. So, it seems impossible to use SQL-clients based on ADO in Merge Replication!

A serious bug in SQL-2005/2008 Replication: Loosing @@IDENTITY value

Hello all!

There is a bug in SQL-2005/2008 Replication system, which may break data integrity, when using @.@.IDENTITY function to update FOREIGN KEY of some table.

When Merge replication is set up, and there is a table article with IDENTITY column in it, after inserting a new row in the table a value of @.@.IDENTITY function does not actually shows just inserted row's identity value.

This issue also generated when performing inserts via ADO.

For details, see my Feedback to Microsoft:

https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=286165

Also, there are other comments on this problem:

http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.data.ado&tid=dcb56477-15fe-413e-a90a-3e1816bc7375&p=1

https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=281682

https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=284124

SQL Server Katmai July CTP has been released. But the bug described above is not resolved there. It still can be generated the same way! However, the feedback is marked as "Resolved"...

|||

it looks like it was resolved as by design. do you have any of the feedback or reasons this was marked by design?

|||

You should not rely on @.@.identity and propgram your solution.

You should rather look at using scope_identity.

|||

Thanks, Greg and Mahesh!

Now I understand, why it market as "Resolved by Design". But there is another problem: ADO itself uses @.@.IDENTITY instead of SCOPE_IDENTITY when inserts a value to a table. So, it seems impossible to use SQL-clients based on ADO in Merge Replication!

A serious bug in SQL-2005/2008 Replication: Loosing @@IDENTITY value

Hello all!

There is a bug in SQL-2005/2008 Replication system, which may break data integrity, when using @.@.IDENTITY function to update FOREIGN KEY of some table.

When Merge replication is set up, and there is a table article with IDENTITY column in it, after inserting a new row in the table a value of @.@.IDENTITY function does not actually shows just inserted row's identity value.

This issue also generated when performing inserts via ADO.

For details, see my Feedback to Microsoft:

https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=286165

Also, there are other comments on this problem:

http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.data.ado&tid=dcb56477-15fe-413e-a90a-3e1816bc7375&p=1

https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=281682

https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=284124

SQL Server Katmai July CTP has been released. But the bug described above is not resolved there. It still can be generated the same way! However, the feedback is marked as "Resolved"...

|||

it looks like it was resolved as by design. do you have any of the feedback or reasons this was marked by design?

|||

You should not rely on @.@.identity and propgram your solution.

You should rather look at using scope_identity.

|||

Thanks, Greg and Mahesh!

Now I understand, why it market as "Resolved by Design". But there is another problem: ADO itself uses @.@.IDENTITY instead of SCOPE_IDENTITY when inserts a value to a table. So, it seems impossible to use SQL-clients based on ADO in Merge Replication!

A question about Log Shipping

If I switching recovery model from Full to Bulk-Logged, will the log
shipping break?
Thanks
LijunHi Lijun,
IMO, it should work eventhough I haven't tried this yet. Log-shipping
criteria is that the database partcipating in log-shipping should be either
in full or bulk-logged recovery mode.
--
Thanks
Yogish