InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comThu, 23 May 2013 21:37:13 GMT20http://www.sqlservercentral.com/Forums/Topic471172-359-1.aspxOMG! Thank you so much for that reply. I've spent the past week trying to set that linked server up. Logging on to the server directly was exactly what I needed.Fri, 06 Jan 2012 13:05:08 GMTchantal_picardhttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspx[url]http://www.iana.org/assignments/port-numbers[/url]Fri, 09 Jul 2010 12:09:16 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspxI'll try to get it written up as an article next week. In the mean time maybe you can answer another quick question. If I am going to set my servers as fixed ports do you know what range of ports is safe? I've already had a case where we set it to a fixed port in the 2700 range and after a reboot that port was no longer available.Fri, 09 Jul 2010 12:05:42 GMTKenneth.Fisherhttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspxNice notes. We'd love this as a one page article, describing the problem, how you solved it, how it works, if you're interested.In terms of the question, I'm not sure there is a way. From what I know of most of these MS services, they are either a range or ports or a specific port. No dynamic way to handle this stuff other than fix a port.Fri, 09 Jul 2010 10:34:20 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspxI've actually been working on the "Double-Hop" problem for over a year now, even with help from someone else who had solved it. And I finally came down to a very simple checklist to resolve the issue. It does require someone who has domain admin authority though to grant the permissions and it is for SQL 2005 and up only. Its more complicated for SQL 2000 and I havn't worked it out yet.Give ServerA and ServerB1) Have 2 service accounts created. Say SVCServerA and SVCServerB2) Have them granted read & write servicePrincipalName3) Assign the service accounts as the startup accounts for the SQL Servers. SVCServerA for ServerA and SVCServerB for ServerB.4) Restart the SQL Services. This causes an SPN to be created (Service Principal Name).5) Once this is done there is no a "Delegation" tab in AD. Have both of your services granted "Trust this user for delegation to any service (Kerberos only)".Now if your security people balk at the "any service" part like mine did they can grant the trust just to the other service account. IE For SVCServerA grant "Trust this user for delegation to specified services only"/"Use Kerberos only"/SVCServerB and vise versa.At this point you should be able to hop between ServerA and ServerB freely.And now for my questionHaving granted a trust from SVCServerA to SVCServerB it is resolved to ServerB:Port. When my port number changes (After a reboot say) the trust is still specific to the other port and my double hop stops working. Does anyone know a way around this other than fixing the ports on my SQL Server?Fri, 09 Jul 2010 10:29:21 GMTKenneth.Fisherhttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspxI had seen almost the same issue here when a .NET Site was trying to use Integrated security to talk to the Db and it was failing with the same error. Login failed for user Null. Not part of....The issue was that there was no application pool set up. It had the default application pool and the app was trying to use it. This caused the error. An application pool was created and then the web app started working.Tue, 19 May 2009 13:08:21 GMTRoy Ernesthttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspxLooks like I had cached credentials to the old machine as the local admin to the machine for an old purpose. oops.... C:\WINDOWS\system32\rundll32.exe keymgr.dll, KRShowKeyMgrI then removed them and all was better.Tue, 19 May 2009 09:39:48 GMTBob Faziohttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspxHaving a similar issue, but unfortunately everything I have read up to this point appears to be for a different problem.First of all, I was able to access this system last week without issue. However, they renamed the machine over the weekend.I have 3 systems in my office, and I can connect using my login from 1 of the 3. The other two I get the error. "Login failed for user ''. The user is not associated with a trusted SQL Server connection"and "SSPI handshake failed with error code 0x8009030c while establishing a connection with integrated security; the connection has been closed."However on the two machines that don't work, if I do a "Run As" using a different domain account, I can connect.Any ideas?Tue, 19 May 2009 09:09:03 GMTBob Faziohttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspx[quote][b]Vivien Xing (8/3/2008)[/b][hr]Another addict seeks advice here.Marios, how did you resolve your problem? Does Microsoft help you anyhow? Any story to share?I encountered the same problem and need to figure it out. I read through this post and think it is very helpful. There is another related link regarding this problem.http://blogs.msdn.com/sql_protocols/archive/2006/08/10/694657.aspxhttp://blogs.msdn.com/sql_protocols/archive/2006/08/10/694657.aspxMy application side says their reports on the web server some times work, some times do not work with the same error as this post discussed. The reports call procedures on SQL2005 64-bit which links to SQL2000. The link above mentioned that token expires. It may be related to my problem. How to deal with this problem? [/quote]Unfortunately, I did not pursue this to completion. It was taking an awful long to figure out, and I needed help from our sysadmin people which were not fully cooperative. So I have put this on the shelf for now.The key is Kerberos delegation, as mentioned in this thread. Kerberos requires configuring SPNs for each computer based on the port number(s) used by SQL Server.Sorry, that's all I have, I hope you are able to solve it.Mon, 04 Aug 2008 04:56:08 GMTMarios Philippopouloshttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspxAnother addict seeks advice here.Marios, how did you resolve your problem? Does Microsoft help you anyhow? Any story to share?I encountered the same problem and need to figure it out. I read through this post and think it is very helpful. There is another related link regarding this problem.http://blogs.msdn.com/sql_protocols/archive/2006/08/10/694657.aspxhttp://blogs.msdn.com/sql_protocols/archive/2006/08/10/694657.aspxMy application side says their reports on the web server some times work, some times do not work with the same error as this post discussed. The reports call procedures on SQL2005 64-bit which links to SQL2000. The link above mentioned that token expires. It may be related to my problem. How to deal with this problem? Sun, 03 Aug 2008 20:56:38 GMTVivien Xinghttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspx[quote][b]K. Brian Kelley (3/31/2008)[/b][hr]This site can be that way. If you look at the Top Points lists you'll see folks who have "binged" in the last 30 days. :)[/quote]And, if you follow its link to the "TotalScores" page you can see who the long-term chronic addicts are. :DMon, 31 Mar 2008 18:15:24 GMTRBarryYounghttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspx[quote][b]Marios Philippopoulos (3/27/2008)[/b][hr]I'll confess I'm addicted to this site...Every time I get an email notification on a new posting, it's as if it goes straight to my veins! :w00t:[/quote]This site can be that way. If you look at the Top Points lists you'll see folks who have "binged" in the last 30 days. :)Mon, 31 Mar 2008 06:35:35 GMTK. Brian Kelleyhttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspxI'll confess I'm addicted to this site...Every time I get an email notification on a new posting, it's as if it goes straight to my veins! :w00t:Thu, 27 Mar 2008 20:18:49 GMTMarios Philippopouloshttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspx[quote][b]K. Brian Kelley (3/27/2008)[/b][hr][quote][b]Marios Philippopoulos (3/27/2008)[/b][hr][quote][b]rbarryyoung (3/26/2008)[/b][hr]On second thought, maybe you should just brung Brian along. ;)[/quote]I don't think I can afford him... ;)[/quote]The problem isn't price. It's time. Life-work balance (and that order is intentional) is hard to find in our industry. [/quote]I hear that. All you have to do is look at the Posting times on some of these replies to prove that (even adjusting for time-zones)!Thu, 27 Mar 2008 20:15:23 GMTRBarryYounghttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspx[quote][b]Marios Philippopoulos (3/27/2008)[/b][hr][quote][b]rbarryyoung (3/26/2008)[/b][hr]On second thought, maybe you should just brung Brian along. ;)[/quote]I don't think I can afford him... ;)[/quote]The problem isn't price. It's time. Life-work balance (and that order is intentional) is hard to find in our industry. Thu, 27 Mar 2008 15:28:11 GMTK. Brian Kelleyhttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspx[quote][b]Marios Philippopoulos (3/27/2008)[/b][hr][quote][b]rbarryyoung (3/26/2008)[/b][hr][quote][b]Marios Philippopoulos (3/24/2008)[/b][hr][quote]So at the moment I'm stuck with a less than ideal scenario, and I want to try the Kerberos-auth option...[/quote]Good luck. Make sure that you've got some good Networking & AD folks available.[/quote]You hit the nail in the head!I'm working with MS on the issue, and they have asked me to do a ton of tests that our IT Support team are reluctant to help me with, even though they themselves cannot fix my issue! I'm in danger of having the case closed my MS because of this! Very frustrating, but at least a learning experience in terms of having to work *[u]harmoniously[/u] :-)* with other people and get the most done in the process! Will see how this pans out...Sometimes I find that working with our IT Support team requires the diplomatic skills of a UN Secretary General! :D[/quote]Well, the good thing is Microsoft is always willing to re-open a case, even if they've archived it. I've been down that road before when I hit roadblocks in our implementation process. Also, depending on the test, some of it you can run yourself with the normal permissions in AD. Some you can't (or shouldn't, like if they ask you to run netmon or something), but depending on the task, you may already have the rights to do it. Things like looking up SPNs, using KerbTray to check whether or not you're getting the right tickets, that kind of stuff you can do. DNS related things, to a certain extent, can be done using nslookup from the command line. If they start asking you to check networking config on the servers, trust relationships, etc., that may be a different story, unfortunately.Thu, 27 Mar 2008 15:27:03 GMTK. Brian Kelleyhttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspx[quote][b]rbarryyoung (3/26/2008)[/b][hr]On second thought, maybe you should just brung Brian along. ;)[/quote]I don't think I can afford him... ;)Thu, 27 Mar 2008 10:13:29 GMTMarios Philippopouloshttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspx[quote][b]rbarryyoung (3/26/2008)[/b][hr][quote][b]Marios Philippopoulos (3/24/2008)[/b][hr][quote]So at the moment I'm stuck with a less than ideal scenario, and I want to try the Kerberos-auth option...[/quote]Good luck. Make sure that you've got some good Networking & AD folks available.[/quote]You hit the nail in the head!I'm working with MS on the issue, and they have asked me to do a ton of tests that our IT Support team are reluctant to help me with, even though they themselves cannot fix my issue! I'm in danger of having the case closed my MS because of this! Very frustrating, but at least a learning experience in terms of having to work *[u]harmoniously[/u] :-)* with other people and get the most done in the process! Will see how this pans out...Sometimes I find that working with our IT Support team requires the diplomatic skills of a UN Secretary General! :DThu, 27 Mar 2008 10:12:15 GMTMarios Philippopouloshttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspxOn second thought, maybe you should just brung Brian along. ;)Wed, 26 Mar 2008 21:20:34 GMTRBarryYounghttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspx[quote][b]Marios Philippopoulos (3/24/2008)[/b][hr][quote]So at the moment I'm stuck with a less than ideal scenario, and I want to try the Kerberos-auth option...[/quote]Good luck. Make sure that you've got some good Networking & AD folks available.Wed, 26 Mar 2008 21:04:54 GMTRBarryYounghttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspx[quote]There's a great document which details how to configure and troubleshoot Kerberos delegation related problems here (it's essential reading for CRM 3.0 configurations where all the tiers are on separate servers):Troubleshooting Kerberos Delegation[/quote]Great link and feedback, thank you!Wed, 26 Mar 2008 07:56:04 GMTMarios Philippopouloshttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspx[quote][b]Marios Philippopoulos (3/24/2008)[/b][hr][quote][b]rbarryyoung (3/24/2008)[/b][hr]Marios: Glad I could help. I lost many days to this problem the first time that I tripped over it.[/quote]Thank you!This problem rears its ugly head in many different ways. It occurs when I attempt to open an SSRS report on my local workstation that connects through Windows auth. to a production instance and surveys user-database permissions. To resolve I need to create a special SQL login with sysadmin permissions on the instance! The alternative would be to map that login to EVERY single user database with [u]db_datareader [/u]permissions, something hard to pull off logistically (and messy).So at the moment I'm stuck with a less than ideal scenario, and I want to try the Kerberos-auth option...[/quote]This is what you're effectively doing and why you see the double hop issue:client (through the web report) -> initial SQL Server (as Windows user) -> linked SQL Server (as Windows user)That's the double-hop issue. Here's what would have to be configured to make Kerberos work in this situation (and it'll require a domain admin/forest admin to do):- Service Principal Names (SPNs) properly configured for the initial SQL Server instance (and if this is on a cluster, the Network name will have to be configured for Kerberos authentication)- Service Principal Names (SPNs) properly configured for the linked SQL Server instance (see above note about cluster config)- Constrained delegation (I'm assuming Windows 2003/2008 AD) for the service account for the first SQL Server instance permitting it to connect and impersonate to the second SQL Server instance- If in a multiple domain environment, where you're crossing domains in any way, using fully qualified domain names (FQDNs) in all computer name references (instead of just mysqlserver, mysqlserver.thedomain.net or what have you).There's a great document which details how to configure and troubleshoot Kerberos delegation related problems here (it's essential reading for CRM 3.0 configurations where all the tiers are on separate servers):[url=http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerbdel.mspx]Troubleshooting Kerberos Delegation[/url]Wed, 26 Mar 2008 05:01:12 GMTK. Brian Kelleyhttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspxHe's avoiding the double-hop issue by switching the security context. Previously you were doing this:client -> web server (as Windows user) -> SQL Server (as Windows user)now you're doing this:client -> web server (as Windows user) -> SQL Server (as SQL Server login)Wed, 26 Mar 2008 04:50:42 GMTK. Brian Kelleyhttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspx[quote][b]rbarryyoung (3/22/2008)[/b][hr][quote][b]Marios Philippopoulos (3/22/2008)[/b][hr]Connections are made using the login's current security context.So in the following query, the login running the query is the same account in whose context the connection is attempted:SELECT * from [server\instance2k].dbName.dbo.tblName;The puzzling thing is that the same user is able to connect to instance server\instance2k through SSMS, while logged on the instance hosting the linked server.[/quote]In your case it is pretty clear what the problem is (not so clear for the OP, who had less detail). What you are running into is almost certainly the "Two Hop Rule", which is that under windows domain security, an impersonated security context cannot re-impersonate (that is, it cannot generate the same impersonation on another server).This is relevant because when you connect from a client to the SQL Server, it impersonates you to generate the security context. In order to get to the linked server using Trusted connections, the security context of your server session would have to be re-impersonated on the target server, and that is not allowed. So even though you can connect directly from your client to both servers, you cannot connect from you client to the first server and then through that to the linked server, because that would be a two-hop impersonation.The way to test to see if this is really the problem is to find a way to get a session on your SQL server without it having to be impersonated and then try to connect to the linked server from there. I know of two ways to do this: 1) Log on to your server at the console or through Remote Desktop, then run your client to connect to the SQL server on the same box; then connect through it to the Linked Server; it should work now. OR.. 2) Write a stored procedure that tries to connect to the linked server and run it using the SQL Agent making sure the the Run As.. is set. (Actually, I am not sure that this still works under Sql2005..)If you ask Microsoft, they will say that the solution to this problem is Kerberos, but I have yet to see anyone successfully use Kerberos to address this problem in a complex multi-domain corporate enterprise network.The solution that everyone ends up using is SQL Logins for server-to-server communications. Not ideal, and not a secure as anyone would like, but it does work.[/quote]The answer isn't just Kerberos, as in Kerberos authentication, but actually Kerberos delegation. Kerberos authentication, by default, is just like NTLM: double-hops aren't permitted. With Kerberos delegation, multiple hops can be set up. Where we typically see this is web browser (client) to web server (first hop) to SQL Server (second hop) all trying to pass the user credentials from the web browser all the way through to the SQL Server. Another instance is SQL Server client to first SQL Server (first hop) to linked SQL Server (second hop), again using the user's credentials the same way. If the security context changes between hops, either by using a "service account" or by using a SQL Server login, then the double hop situation doesn't occur.With respect to complex multi-domain environments, the big thing is forest level. In Windows 2000 AD you don't have forest level trusts. So domains from one forest can't talk to domains in other forests and do Kerberos authentication. The forest is the Kerberos realm boundary. Windows will drop back to NTLM, which absolutely does not support more than one hop (by design). In Windows 2003 and above domains, Forest-level trusts are permitted, which means forests can have Kerberos authentication between domains in the separate forests. Wed, 26 Mar 2008 04:46:37 GMTK. Brian Kelleyhttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspxDon't know how our DBA resolved this, but he gave me a new ID/password that I've used in my connectionString. Not a very wise move but for now that's all I can do, to include those credentials in my connection string. cheersWed, 26 Mar 2008 00:20:36 GMTJani Lanehttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspx[quote][b]Jani Lane (3/18/2008)[/b][hr]Good day!Don't know much about security, but I've created my web service function to return a dataset from SQL Server 2000. When I invoked the function it is giving me this error in the page although I can generate a dataset and connect to the db, only when invoking the web service that I'm getting this.Need help please.Thanks[/quote]BTW, apologies for cutting into this thread with my own problem! ;)I think it is the same as what you posted, but, if not, pls let us know.thx!Mon, 24 Mar 2008 11:43:41 GMTMarios Philippopouloshttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspx[quote][b]rbarryyoung (3/24/2008)[/b][hr]Marios: Glad I could help. I lost many days to this problem the first time that I tripped over it.[/quote]Thank you!This problem rears its ugly head in many different ways. It occurs when I attempt to open an SSRS report on my local workstation that connects through Windows auth. to a production instance and surveys user-database permissions. To resolve I need to create a special SQL login with sysadmin permissions on the instance! The alternative would be to map that login to EVERY single user database with [u]db_datareader [/u]permissions, something hard to pull off logistically (and messy).So at the moment I'm stuck with a less than ideal scenario, and I want to try the Kerberos-auth option...Mon, 24 Mar 2008 11:41:54 GMTMarios Philippopouloshttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspxMarios: Glad I could help. I lost many days to this problem the first time that I tripped over it.Mon, 24 Mar 2008 09:14:47 GMTRBarryYounghttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspxIt is indeed as you say.When running the same SELECT linked-server query while RDP'd directly on the source server (the server instance to which the linked server is added) it works! The error occurs when running the query while connected remotely to the server (through SSMS).So it looks like it is indeed a double-hop integrated authentication issue.We are running this query from a SQL job so we just need to give the SQL Agent account sufficient privileges on the target instance for it to be able to view the data.Mon, 24 Mar 2008 08:31:36 GMTMarios Philippopouloshttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspx[quote][b]Marios Philippopoulos (3/22/2008)[/b][hr]Connections are made using the login's current security context.So in the following query, the login running the query is the same account in whose context the connection is attempted:SELECT * from [server\instance2k].dbName.dbo.tblName;The puzzling thing is that the same user is able to connect to instance server\instance2k through SSMS, while logged on the instance hosting the linked server.[/quote]In your case it is pretty clear what the problem is (not so clear for the OP, who had less detail). What you are running into is almost certainly the "Two Hop Rule", which is that under windows domain security, an impersonated security context cannot re-impersonate (that is, it cannot generate the same impersonation on another server).This is relevant because when you connect from a client to the SQL Server, it impersonates you to generate the security context. In order to get to the linked server using Trusted connections, the security context of your server session would have to be re-impersonated on the target server, and that is not allowed. So even though you can connect directly from your client to both servers, you cannot connect from you client to the first server and then through that to the linked server, because that would be a two-hop impersonation.The way to test to see if this is really the problem is to find a way to get a session on your SQL server without it having to be impersonated and then try to connect to the linked server from there. I know of two ways to do this: 1) Log on to your server at the console or through Remote Desktop, then run your client to connect to the SQL server on the same box; then connect through it to the Linked Server; it should work now. OR.. 2) Write a stored procedure that tries to connect to the linked server and run it using the SQL Agent making sure the the Run As.. is set. (Actually, I am not sure that this still works under Sql2005..)If you ask Microsoft, they will say that the solution to this problem is Kerberos, but I have yet to see anyone successfully use Kerberos to address this problem in a complex multi-domain corporate enterprise network.The solution that everyone ends up using is SQL Logins for server-to-server communications. Not ideal, and not a secure as anyone would like, but it does work.Sat, 22 Mar 2008 14:40:22 GMTRBarryYounghttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspxConnections are made using the login's current security context.So in the following query, the login running the query is the same account in whose context the connection is attempted:SELECT * from [server\instance2k].dbName.dbo.tblName;The puzzling thing is that the same user is able to connect to instance server\instance2k through SSMS, while logged on the instance hosting the linked server.Sat, 22 Mar 2008 13:03:15 GMTMarios Philippopouloshttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspxYou need to check the linked server credentials to see what's there. You can either have set credentials for everyone, rights for some people and not others, or pass through credentials.Check in SSMS how the linked server security is configured.Sat, 22 Mar 2008 10:58:21 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspxI'm having the exact same issue when using a linked server on a SQL Server 2005 instance (target is a SQL 2000 instance).The exact error is:[quote]OLE DB provider "SQLNCLI" for linked server "server\instance" returned message "Communication link failure".Msg 10054, Level 16, State 1, Line 0TCP Provider: An existing connection was forcibly closed by the remote host.Msg 18452, Level 14, State 1, Line 0[b]Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection.[/b][/quote]The user getting this error is able to successfully connect to the target instance on SSMS, while logged on the source sql 2005 instance where the linked server is created.The linked server is created by the following command (note that security is configured for windows integrated auth., NOT SQL auth.):[quote]EXEC sp_addlinkedserver 'server\instance2k', N'SQL Server';[/quote]The user is getting the error above after running:[quote]select * from [server\instance2k].DBNAME.dbo.TableName;[/quote]I find this issue odd because, as I mentioned, the user is able to connect with no problems to [i]server\instance2k[/i] on SSMS, while logged on the sql2005 instance.I strongly suspect this is the exact same problem as that posted initially on this thread.Sat, 22 Mar 2008 09:13:48 GMTMarios Philippopouloshttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspxWhen you connect, you use your credentials, likely your Windows account. When the web service connects, it's probably using different credentials, probably IIS credentials. Be sure those have access to the SQL server.Tue, 18 Mar 2008 14:49:35 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspxusual reason for this error is the sql instance is set to only accept windows authenticated logins but you are trying to connect with a sql authenticated ID. check the properties on your sql instance. If this is your problem will need to change authentication mode to windows and sql authentication, which will require a sql bounce to take effect....or connect with a windows id, which is more secureTue, 18 Mar 2008 14:19:40 GMTgeorge sibbaldhttp://www.sqlservercentral.com/Forums/Topic471172-359-1.aspxGood day!Don't know much about security, but I've created my web service function to return a dataset from SQL Server 2000. When I invoked the function it is giving me this error in the page although I can generate a dataset and connect to the db, only when invoking the web service that I'm getting this.Need help please.ThanksTue, 18 Mar 2008 13:55:06 GMTJani Lane