When I first installed BI Studio everything was working fine, but I went into it today and I noticed that the FTP task seems to be missing, I can't see it in the toolbox, everything else appears to be their but not that.
Any idea how I can get this back, I really don't wont to uninstall and reinstall at the moment, and I'm not even sure if that would work.
ThanksRight-click the toolbox, Choose Items. Select the SSIS Control Flow page and have a look for any missing tasks, those not checked.
I have designed an SSIS that needs to download a set of files via ftp. The ftp is working fine under Business Studio. When I move it to The server and try runing the package I'm getting the following errors:
Error: Unable to connect to FTP server using "FTP Server"
Error: An error occurred in the requested FTP operation. Detailed error description: The password was not allowed.
This is not my first FTP in SSIS, so I also have the following item set:
Protectionlevel = EncryptProtectedWithPassword
I have several other FTP packages that go to the exact same server, with the exact same user ID and password that are working.
What am I missing?
Since noone is responding...
I also tried changing the protection level to "DontSaveEncrypted" and set up a package configuration with the password in it. I thought this would work, but I'm still getting the same messages.
|||This is an FTP server error, not an SSIS related error.Search the Internet for "The password was not allowed." for discussions on this message.|||
Thanks for replying Phil.
If this is an FTP server error, why does it work in one package, but not in another that's using the exact same connection?
And why does it work in SSIS designer?
I have two similar packages that are both experiencing this issue.
I need to add a script step to generate an incrementing id for the packages.
Once I add the script step, and then save the package, next time I open the package I get a "Microsoft Visual Studio has encountered a problem and needs to close" error which kills off Visual Studio.
The error signature is:
EventType: clr20r3
P1: devenv.exe
P2: 8.0.50727.762
P3: 45716759
P4: microsoft.sqlserver.txscript
P5: 9.0.242.0
P6: 443f5ab8
P7: 67
P8: d
P9: bbp0yyyc15o2dbouwcacz2m0bodqkotn
If I move the error window to one side, delete the whole Script step, and save the Package, then I can reopen the package again without the error occurring.
Here is the actual code in my script step (in case its of any assistance...)
(I have retyped it from a printout, so it may not be 100%. DOCID is supposed to increment from 1. DREF1 is a system-unique id, that takes up from where the last batch left off, and is a string prefixed by "MP")
Code Snippet
Imports System
Imports System.Data
Imports System.math
Imports Microsoft.SqlServer.Dts.Pipeline.Wrapper
Imports Microsoft.SqlServer.Dta.Runtime.Wrapper
Public Class ScriptMain
Inherits UserComponent
Dim ndx as Int32 = 0
Public Overrides Sub Input0_ProcessInputRow(Byval Row as Input0Buffer)
'
' Add your code here
'
Dim dref as String
ndx = ndx + 1
Row.DOCID = ndx
dref = "MP" + Ctype(ndx + Variables.MPIDOrig, String)
Row.DREF1 = dref
End Sub
Protected Overrides Sub finalize()
Variables.MPID = ndx + Variables.MPIDOrig
MyBase.Finalize()
End Sub
End Class
I have found that when I take out the finalize() function, Visual Studio no longer crashes.
Can anyone suggest a different way to achieve what I am trying to achieve?
|||Could you to put it into PostExecute()?
Thanks,
Bob
|||Thanks, yes this was the answer.
It was a bit frustrating, as a relative newbie to SSIS, to find that the Finalize method caused this sort of behaviour, and it wasn't immediately obvious that PostExecute should be used instead.
(By which I mean I actually had to read deeper than jsut fiddling about in the IDE.)
I have two similar packages that are both experiencing this issue.
I need to add a script step to generate an incrementing id for the packages.
Once I add the script step, and then save the package, next time I open the package I get a "Microsoft Visual Studio has encountered a problem and needs to close" error which kills off Visual Studio.
The error signature is:
EventType: clr20r3
P1: devenv.exe
P2: 8.0.50727.762
P3: 45716759
P4: microsoft.sqlserver.txscript
P5: 9.0.242.0
P6: 443f5ab8
P7: 67
P8: d
P9: bbp0yyyc15o2dbouwcacz2m0bodqkotn
If I move the error window to one side, delete the whole Script step, and save the Package, then I can reopen the package again without the error occurring.
Here is the actual code in my script step (in case its of any assistance...)
(I have retyped it from a printout, so it may not be 100%. DOCID is supposed to increment from 1. DREF1 is a system-unique id, that takes up from where the last batch left off, and is a string prefixed by "MP")
Code Snippet
Imports System
Imports System.Data
Imports System.math
Imports Microsoft.SqlServer.Dts.Pipeline.Wrapper
Imports Microsoft.SqlServer.Dta.Runtime.Wrapper
Public Class ScriptMain
Inherits UserComponent
Dim ndx as Int32 = 0
Public Overrides Sub Input0_ProcessInputRow(Byval Row as Input0Buffer)
'
' Add your code here
'
Dim dref as String
ndx = ndx + 1
Row.DOCID = ndx
dref = "MP" + Ctype(ndx + Variables.MPIDOrig, String)
Row.DREF1 = dref
End Sub
Protected Overrides Sub finalize()
Variables.MPID = ndx + Variables.MPIDOrig
MyBase.Finalize()
End Sub
End Class
I have found that when I take out the finalize() function, Visual Studio no longer crashes.
Can anyone suggest a different way to achieve what I am trying to achieve?
|||Could you to put it into PostExecute()?
Thanks,
Bob
|||Thanks, yes this was the answer.
It was a bit frustrating, as a relative newbie to SSIS, to find that the Finalize method caused this sort of behaviour, and it wasn't immediately obvious that PostExecute should be used instead.
(By which I mean I actually had to read deeper than jsut fiddling about in the IDE.)
sqlI have two similar packages that are both experiencing this issue.
I need to add a script step to generate an incrementing id for the packages.
Once I add the script step, and then save the package, next time I open the package I get a "Microsoft Visual Studio has encountered a problem and needs to close" error which kills off Visual Studio.
The error signature is:
EventType: clr20r3
P1: devenv.exe
P2: 8.0.50727.762
P3: 45716759
P4: microsoft.sqlserver.txscript
P5: 9.0.242.0
P6: 443f5ab8
P7: 67
P8: d
P9: bbp0yyyc15o2dbouwcacz2m0bodqkotn
If I move the error window to one side, delete the whole Script step, and save the Package, then I can reopen the package again without the error occurring.
Here is the actual code in my script step (in case its of any assistance...)
(I have retyped it from a printout, so it may not be 100%. DOCID is supposed to increment from 1. DREF1 is a system-unique id, that takes up from where the last batch left off, and is a string prefixed by "MP")
Code Snippet
Imports System
Imports System.Data
Imports System.math
Imports Microsoft.SqlServer.Dts.Pipeline.Wrapper
Imports Microsoft.SqlServer.Dta.Runtime.Wrapper
Public Class ScriptMain
Inherits UserComponent
Dim ndx as Int32 = 0
Public Overrides Sub Input0_ProcessInputRow(Byval Row as Input0Buffer)
'
' Add your code here
'
Dim dref as String
ndx = ndx + 1
Row.DOCID = ndx
dref = "MP" + Ctype(ndx + Variables.MPIDOrig, String)
Row.DREF1 = dref
End Sub
Protected Overrides Sub finalize()
Variables.MPID = ndx + Variables.MPIDOrig
MyBase.Finalize()
End Sub
End Class
I have found that when I take out the finalize() function, Visual Studio no longer crashes.
Can anyone suggest a different way to achieve what I am trying to achieve?
|||Could you to put it into PostExecute()?
Thanks,
Bob
|||Thanks, yes this was the answer.
It was a bit frustrating, as a relative newbie to SSIS, to find that the Finalize method caused this sort of behaviour, and it wasn't immediately obvious that PostExecute should be used instead.
(By which I mean I actually had to read deeper than jsut fiddling about in the IDE.)
For instance, in one database EM shows me that I have 1200MB free in the data file and 400MB free in the log file. It also says, at the top of the taskpad view, that I have 0 free space in the database - I'm not sure how they relate, but in SSMS the only number that I can see is the 0. It also takes several mouse clicks and scrolling over to see the breakdown of the data and log sizes.
In the object browser, highlight your database. On the right pane, click on the Summary tab. (If it is not there, hit F7.) Take a look at the Report dropdown. I think you'll like the Disk Usage report a little bit better than EM's archaic taskpad view. A wrote in message news:c99645b4-1bd4-45d3-8a71-46591c4597dd@.discussions.microsoft.com...
> In Enterprise Manager, the taskpad view showed me how much space is
> available in the data and log files. Is this information available
> anywhere in SSMS? >
> For instance, in one database EM shows me that I have 1200MB free in the
> data file and 400MB free in the log file. It also says, at the top of
> the taskpad view, that I have 0 free space in the database - I'm not
> sure how they relate, but in SSMS the only number that I can see is the
> 0. It also takes several mouse clicks and scrolling over to see the
> breakdown of the data and log sizes. >
>|||Thanks for the suggestion. However, the Report dropdown is greyed out on my Summary tab. I guess that's because we didn't install Reporting Services?
|||No, I don't have reporting services installed either. Are you sure the focus in the object browser is on a database name, like I originally suggested? >> In the object browser, highlight your database. The Summary tab is context sensitive, so if in the object browser you have highlighted "assemblies" or an individual stored procedure or table or the database diagrams node or server objects, the reports dropdown will be greyed out, because there are no reports relevant to those objects. A wrote in message news:6134a1d2-8631-434a-897c-6308dc7fef63@.discussions.microsoft.com...
> Thanks for the suggestion. However, the Report dropdown is greyed out on
> my Summary tab. I guess that's because we didn't install Reporting
> Services? >
>|||You're right - I must have had the focus in the wrong place. It is a nice report and contains a lot of useful information, but it took 2 minutes to run on an otherwise idle server (with 4 Xeon 3.6 processors in 64 bit mode, 4GB of RAM, and data and log on separate RAID 5 spindles). I would still like to have something that quickly gives me total size and free space at the file level.|||
> nice report and contains a lot of useful information, but it took 2
> minutes to run on an otherwise idle server The first time you ran it? Was that the only time you've run it? It may have had to do some background processing and/or caching the first time. My server is less powerful than that (virtual machine with 2 CPUs and 3 GB allocated), and it resides 60 miles away in our data center, and the report took 4 seconds to load on my paltry workstation (dual xeon 3.4, 2 GB). And I use this report all the time; if it was slow by nature and this instance wasn't a freak phenomenen, I'm sure I would have observed this issue before? A
> our database has over 1100 tables. Ah, I see. Well, "quick" is a pretty lofty goal, then, unless you want relatively stale data. You could run queries on the hour that store this information into your own tables, then that query will be quick, but it won't be up-to-the-minute. A
|||So, in summary, if I am monitoring a SQL2000 server in SSMS 05 then there is no way for me to see the free space on my data files. AND if it's a large 2005 database I have to wait a long time for the report because it wants to give me details on every table. So much for a quick check of my systems!|||I agree. Monitoring free space in data files is something a DBA does frequently, and so in SQL2000 Enterprise Manager I often used the Taskpad view for a quick check (even though it was buggy and would sometimes throw interface errors). I had been hunting for the same kind of quick reporting in SQL 2005 Management Studio, and thanks to this thread I figured it out... but I am STILL waiting for my first report to come up on Disk Usage, and it has been over 5 minutes now! I manage a large number of SAP databases, and this is the first one to be configured on SQL 2005 (the others are still 2000, but they will be upgraded soon). This is one of the smaller ones, at only 20 GB in size, but it still has 27,000 tables. I wonder what will happen when I move our 70 GB R/3 database onto this platform? Also, although I haven't checked this out yet, it appears that this disk usage report may be putting a certain amount of load on the server, based on anecdotal observation. That can't be good, if true.
It's true that I can get the information I want on any given single database very quickly by logging into the SAP application and running application-specific database monitor tools (and if the application can do it so quickly, why can't the Disk Usage report? After all, it's just a collection of system stored procedures like sp_spaceused with the output presented graphically). However, when trying to quickly get status on 20+ servers, it's a little tedious to log into each one individually, whereas the Taspad could move through them a little quicker (even though it's still one at a time).
Ok, after more than 10 minutes of execution time while writing this post, the Disk Usage report finally came back with something. However, the information is not what I had hoped for. It tells me "the information needed to display a summary page for the selected object is not available" and throws an error about "object reference not set to an instance of an object." It took 10 minutes to get to that?
|||I can do you one better. I used the TaskPad the way you did -- space problems can be seen at a glance. I moved a db instance from 2000 to 2005, but we are running in 2000 compatibility mode until we can make some code changes. When I try to run the space report in Management Studio, it barks at me for being in 2000 compatibility mode. I can't hit the dbs from EM and I can't get the data in Managment Studio until I switch compatibility mode (and then I'll have a long running on-line report...lucky me).
I think in an effort to use their own framework and tools, Microsoft has taken away the beauty of quick access to data in this case. That's a lot of extra work to break something that already worked really pretty well.
|||OK, further research uncovered the following:
http://www.sqlservercentral.com/columnists/bBaliner/quicklyviewingavailablespace.asp
I tweaked it by adding total space to the mix:
SELECT name AS NameOfFile, size/128.0 AS TotalSpaceInMB,size/128.0 -CAST(FILEPROPERTY(name, 'SpaceUsed' )AS int)/128.0 AS AvailableSpaceInMB
FROM dbo.SYSFILES
Kudos to Boris Baliner!
For instance, in one database EM shows me that I have 1200MB free in the data file and 400MB free in the log file. It also says, at the top of the taskpad view, that I have 0 free space in the database - I'm not sure how they relate, but in SSMS the only number that I can see is the 0. It also takes several mouse clicks and scrolling over to see the breakdown of the data and log sizes.In the object browser, highlight your database.
On the right pane, click on the Summary tab.
(If it is not there, hit F7.)
Take a look at the Report dropdown. I think you'll like the Disk Usage
report a little bit better than EM's archaic taskpad view.
A
wrote in message
news:c99645b4-1bd4-45d3-8a71-46591c4597dd@.discussions.microsoft.com...
> In Enterprise Manager, the taskpad view showed me how much space is
> available in the data and log files. Is this information available
> anywhere in SSMS?
>
> For instance, in one database EM shows me that I have 1200MB free in the
> data file and 400MB free in the log file. It also says, at the top of
> the taskpad view, that I have 0 free space in the database - I'm not
> sure how they relate, but in SSMS the only number that I can see is the
> 0. It also takes several mouse clicks and scrolling over to see the
> breakdown of the data and log sizes.
>
>|||Thanks for the suggestion. However, the Report dropdown is greyed out on my Summary tab. I guess that's because we didn't install Reporting Services?|||No, I don't have reporting services installed either. Are you sure the
focus in the object browser is on a database name, like I originally
suggested?
>> In the object browser, highlight your database.
The Summary tab is context sensitive, so if in the object browser you have
highlighted "assemblies" or an individual stored procedure or table or the
database diagrams node or server objects, the reports dropdown will be
greyed out, because there are no reports relevant to those objects.
A
wrote in message
news:6134a1d2-8631-434a-897c-6308dc7fef63@.discussions.microsoft.com...
> Thanks for the suggestion. However, the Report dropdown is greyed out on
> my Summary tab. I guess that's because we didn't install Reporting
> Services?
>
>|||You're right - I must have had the focus in the wrong place. It is a nice report and contains a lot of useful information, but it took 2 minutes to run on an otherwise idle server (with 4 Xeon 3.6 processors in 64 bit mode, 4GB of RAM, and data and log on separate RAID 5 spindles). I would still like to have something that quickly gives me total size and free space at the file level.|||
> nice report and contains a lot of useful information, but it took 2
> minutes to run on an otherwise idle server
The first time you ran it? Was that the only time you've run it? It may
have had to do some background processing and/or caching the first time.
My server is less powerful than that (virtual machine with 2 CPUs and 3 GB
allocated), and it resides 60 miles away in our data center, and the report
took 4 seconds to load on my paltry workstation (dual xeon 3.4, 2 GB). And
I use this report all the time; if it was slow by nature and this instance
wasn't a freak phenomenen, I'm sure I would have observed this issue before?
A
|||It consitently takes over 2 minutes for our main databases. I suspect it has something to do with the size of the database or number of tables - our database has over 1100 tables. When I tried it on a much smaller database, it came back within a few seconds.|||> our database has over 1100 tables.
Ah, I see. Well, "quick" is a pretty lofty goal, then, unless you want
relatively stale data. You could run queries on the hour that store this
information into your own tables, then that query will be quick, but it
won't be up-to-the-minute.
A
|||So, in summary, if I am monitoring a SQL2000 server in SSMS 05 then there is no way for me to see the free space on my data files. AND if it's a large 2005 database I have to wait a long time for the report because it wants to give me details on every table. So much for a quick check of my systems!|||I agree. Monitoring free space in data files is something a DBA does frequently, and so in SQL2000 Enterprise Manager I often used the Taskpad view for a quick check (even though it was buggy and would sometimes throw interface errors). I had been hunting for the same kind of quick reporting in SQL 2005 Management Studio, and thanks to this thread I figured it out... but I am STILL waiting for my first report to come up on Disk Usage, and it has been over 5 minutes now! I manage a large number of SAP databases, and this is the first one to be configured on SQL 2005 (the others are still 2000, but they will be upgraded soon). This is one of the smaller ones, at only 20 GB in size, but it still has 27,000 tables. I wonder what will happen when I move our 70 GB R/3 database onto this platform? Also, although I haven't checked this out yet, it appears that this disk usage report may be putting a certain amount of load on the server, based on anecdotal observation. That can't be good, if true.
It's true that I can get the information I want on any given single database very quickly by logging into the SAP application and running application-specific database monitor tools (and if the application can do it so quickly, why can't the Disk Usage report? After all, it's just a collection of system stored procedures like sp_spaceused with the output presented graphically). However, when trying to quickly get status on 20+ servers, it's a little tedious to log into each one individually, whereas the Taspad could move through them a little quicker (even though it's still one at a time).
Ok, after more than 10 minutes of execution time while writing this post, the Disk Usage report finally came back with something. However, the information is not what I had hoped for. It tells me "the information needed to display a summary page for the selected object is not available" and throws an error about "object reference not set to an instance of an object." It took 10 minutes to get to that?
|||I can do you one better. I used the TaskPad the way you did -- space problems can be seen at a glance. I moved a db instance from 2000 to 2005, but we are running in 2000 compatibility mode until we can make some code changes. When I try to run the space report in Management Studio, it barks at me for being in 2000 compatibility mode. I can't hit the dbs from EM and I can't get the data in Managment Studio until I switch compatibility mode (and then I'll have a long running on-line report...lucky me).
I think in an effort to use their own framework and tools, Microsoft has taken away the beauty of quick access to data in this case. That's a lot of extra work to break something that already worked really pretty well.
|||OK, further research uncovered the following:
http://www.sqlservercentral.com/columnists/bBaliner/quicklyviewingavailablespace.asp
I tweaked it by adding total space to the mix:
SELECT name AS NameOfFile, size/128.0 AS TotalSpaceInMB,size/128.0 -CAST(FILEPROPERTY(name, 'SpaceUsed' )AS int)/128.0 AS AvailableSpaceInMB
FROM dbo.SYSFILES
Kudos to Boris Baliner!
For instance, in one database EM shows me that I have 1200MB free in the data file and 400MB free in the log file. It also says, at the top of the taskpad view, that I have 0 free space in the database - I'm not sure how they relate, but in SSMS the only number that I can see is the 0. It also takes several mouse clicks and scrolling over to see the breakdown of the data and log sizes.
I agree. Monitoring free space in data files is something a DBA does frequently, and so in SQL2000 Enterprise Manager I often used the Taskpad view for a quick check (even though it was buggy and would sometimes throw interface errors). I had been hunting for the same kind of quick reporting in SQL 2005 Management Studio, and thanks to this thread I figured it out... but I am STILL waiting for my first report to come up on Disk Usage, and it has been over 5 minutes now! I manage a large number of SAP databases, and this is the first one to be configured on SQL 2005 (the others are still 2000, but they will be upgraded soon). This is one of the smaller ones, at only 20 GB in size, but it still has 27,000 tables. I wonder what will happen when I move our 70 GB R/3 database onto this platform? Also, although I haven't checked this out yet, it appears that this disk usage report may be putting a certain amount of load on the server, based on anecdotal observation. That can't be good, if true.
It's true that I can get the information I want on any given single database very quickly by logging into the SAP application and running application-specific database monitor tools (and if the application can do it so quickly, why can't the Disk Usage report? After all, it's just a collection of system stored procedures like sp_spaceused with the output presented graphically). However, when trying to quickly get status on 20+ servers, it's a little tedious to log into each one individually, whereas the Taspad could move through them a little quicker (even though it's still one at a time).
Ok, after more than 10 minutes of execution time while writing this post, the Disk Usage report finally came back with something. However, the information is not what I had hoped for. It tells me "the information needed to display a summary page for the selected object is not available" and throws an error about "object reference not set to an instance of an object." It took 10 minutes to get to that?
|||I can do you one better. I used the TaskPad the way you did -- space problems can be seen at a glance. I moved a db instance from 2000 to 2005, but we are running in 2000 compatibility mode until we can make some code changes. When I try to run the space report in Management Studio, it barks at me for being in 2000 compatibility mode. I can't hit the dbs from EM and I can't get the data in Managment Studio until I switch compatibility mode (and then I'll have a long running on-line report...lucky me).
I think in an effort to use their own framework and tools, Microsoft has taken away the beauty of quick access to data in this case. That's a lot of extra work to break something that already worked really pretty well.
|||OK, further research uncovered the following:
http://www.sqlservercentral.com/columnists/bBaliner/quicklyviewingavailablespace.asp
I tweaked it by adding total space to the mix:
SELECTnameAS NameOfFile,size/128.0 AS TotalSpaceInMB,size/128.0 -CAST(FILEPROPERTY(name,'SpaceUsed')ASint)/128.0 AS AvailableSpaceInMB
FROM dbo.SYSFILES
Kudos to Boris Baliner!
> nice report and contains a lot of useful information, but it took 2
> minutes to run on an otherwise idle server The first time you ran it? Was that the only time you've run it? It may have had to do some background processing and/or caching the first time. My server is less powerful than that (virtual machine with 2 CPUs and 3 GB allocated), and it resides 60 miles away in our data center, and the report took 4 seconds to load on my paltry workstation (dual xeon 3.4, 2 GB). And I use this report all the time; if it was slow by nature and this instance wasn't a freak phenomenen, I'm sure I would have observed this issue before? A
> our database has over 1100 tables. Ah, I see. Well, "quick" is a pretty lofty goal, then, unless you want relatively stale data. You could run queries on the hour that store this information into your own tables, then that query will be quick, but it won't be up-to-the-minute. A
|||So, in summary, if I am monitoring a SQL2000 server in SSMS 05 then there is no way for me to see the free space on my data files. AND if it's a large 2005 database I have to wait a long time for the report because it wants to give me details on every table. So much for a quick check of my systems!If you connect to a server and open a query in SQL Managment studio (2005) and looses connection and then regain the connection, when you try to run the query it gives me a "TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host."
This happens against both 2005 and 2000 servers.
If I re-run the query it works.
However, this happens in our VB.NET app as well for clients with Wireless connections.
So, something has changed in Framework 2.0 regarding this, does anyone know how to tell the client to not throw this error and just try connecting the server instead which will work?
Hi,The SqlClient provider does not retry operations if the underlying connection is "broken" (e.g. closed by the server or by a glitch in the network). SQL Server Management Studio retries by trying to open the connection again.
One factor that affects this behavior is whether or not you have connection pooling enabled. Did you include "pooling=false" in your connection string?
This behavior should not have changed from 1.1 to 2.0. Did your 1.1 application behave differently? What error did you get (if any) on 1.1?
Pablo Castro
Program Manager - ADO.NET Team
Microsoft Corp.|||I have not changed anything from 1.1 to 2.0.
(its a 1.1 converted project to 2.0)
No, I did not get any errors like this in 1.1
I dont have Pooling=False, Neither do I want it that way (large app with tons of connections).
as stated it happens BOTH in Sql Management Studio as well as in any VB.NET app, it happens on several diffrent companies on diffrent continents, against diffrent SQL Servers.
VPN Clients, WIFI Clients are hit hardest (they have tiny drops in connections often)|||Bumping this.
Any resolution yet?
Basically, I cannot run any long running queries on computers with SQL Management Studio + Framework 2.0 installed over VPN, Not even in the OLD Query Analyzer anymore(diffrent error, same meaning).
However, on my untouched laptop, that has the old SQL Server Client Tools installed, it works fine on the same VPN connection.
Even on LAN it happens quite frequently, I got my app on about 150 clients, they catched this error about 40 times today.|||This looks really weird. I'll talk to a few other folks in the protocols team to see if I get more ideas to help you out.
There is one bit that particularly gets my attention: the OLD query analyzer uses the old native data-access stack; the SQL Server 2005 setup, or the VS 2005 setup, do not touch any of those bits at all. So, if you're getting the same behavior from the old query analyzer, that may indicate that there was something else that changed and may be causing this glitch. Do you get failures in QA as often as you get with the other clients? What error do you get in the QA case?
I'll reply again to this thread once I have more details or have someone do it.
Regards,
Pablo Castro
Program Manager - ADO.NET Team
Microsoft Corporation|||Hi Fredrik,
It appears that Sqlclient grabs a connection from the pool that has already been closed because of a network error and reports an error when it tries to write to the socket. I can't understand why the 1.1 framework would be less susceptible to these network errors than the 2.0 framework. Would you be able to take a client-side trace that captures the error and send it to me along with the server's error log? You can email me the files at ilsung@.microsoft.com. The instructions for setting up the trace are here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnadonet/html/tracingdataaccess.asp . Also, if you know of a way for us to repro this, that would be great.
Thanks,
Il-Sung Lee
Program Manager, SQL Server Protocols
Microsoft Corp.
This posting is provided "AS IS" with no warranties, and confers no rights.|||I will test the tracing on my home computer which is connected over VPN.
However, Reproducing it in 2.0 enviroment is easy.
Open a SQL Query in SQL Management studio to a server.
Enter a simple query, Run the query, when its completed, disable the network connection, and immediatly enable it again, re-run the query when the network is back up again and you will get the error:
A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)
If I remember correctly, the same procedure should work for RTM bits. Is it not working for you?
Thanks,
Pablo Castro
Program Manager - ADO.NET Team
Microsoft Corporation
No, I did not get the debug trace function to work, it simply dont dump any data, dont know why.
Anyway.
I found a setting in the SQL Configuration Manager, on TCP/IP Protocol (native) there is KeepAlive and KeepAliveInterval that I am testing a little with.
I sat those settings to zero, eg no keepalive checking I guess, will see how that turns out.
|||Please let everyone know how this goes. I'm having the exact same issue with my application. Thanks!|||
So far 100% success, I left my app running yesterday, and it hadnt crashed still today, one day later. Before the change it only took about 10 minutes on my WiFi before I got a error.
Question is how you can change those values for clients only have .NET framework 2.0 installed (there is no registry entry for that one pre-defined). Registry entry is only present on those clients that have SQL 2005 Client tools installed.
I gonna look a little further with Regmon later this week and see if its just enough to create the registry entry on a "normal" client.
|||I get the same error. It even occurs between my sql server management studio and the sql instance on the network.
The client has the release version while the sql instance is sql server 2005 beta2. Could this be the issue?
Error connecting to SQLSERVER1\ANINSTANCE. Err: A connection was successfully established with the server, but then an error occurred during the login process. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)
This is a project i converted from 1.1 to 2.0.
The old saved 1.1 project connects without any problems.
It really looks like a framework 2.0 issue.
|||
It would be good if you could try this against a final version of SQL Server. The fact that the beta 2 server is dropping the connection during login is not that surprising, it may be due to a protocol version mismatch detected during the login handshake.
So I wouldn't consider this and the other issue discussed in this thread to be the same thing.
Pablo Castro
Program Manager - ADO.NET Team
Microsoft Corporation
