First SQL2K5 server install performance issues

This is comparing performance between two machines...the first is our
current SQL2000 server
Dual 3Ghz Xeons on dual channel scsi drives.
New machine
Dual 3.6Ghz 64-bit Xeons dual channel scsi
SCSI controller in each box is identical as is the drive configuration and
file placement.
I know this may not be a very clear view of the performance but I certainly
expected more from the new server.
We have a table tblMLOS which contains 392468 rows. This following script
after repeated executions runs consistently at 9 seconds on the old server
and 15-17 seconds on the new 64-bit machine. Are we missing something here?
This just doesn't seem right.
The table structure is very simple:
create table tblMLOS
(
lngID int,
lngSponsor int,
lngSponsor2 int,
lngSponsor3 int,
strSponsorType varchar(20)
)
---
declare @.lngCount int
declare @.lngID int
declare curID cursor for
select lngID from tblmlos
set @.lngCount=0
open curID
fetch next from curID into @.lngID
while @.@.fetch_status=0 begin
set @.lngCount=@.lngCount+1
fetch next from curID into @.lngID
end
close curID
deallocate curID
select @.lngCount64 bit will not always be quicker, your code will be purely CPU bound , and
probably only use 1 cpu, the difference in CPU is not much.
Not sure why you are not just doing
select count(1) from lngID from tblmlos
This probably will be quicker.
--
Simon Sabin
SQL Server MVP
http://sqljunkies.com/weblog/simons
"Tim Greenwood" <tim_greenwood A-T yahoo D-O-T com> wrote in message
news:eFa%23wF%23YGHA.3400@.TK2MSFTNGP02.phx.gbl...
> This is comparing performance between two machines...the first is our
> current SQL2000 server
> Dual 3Ghz Xeons on dual channel scsi drives.
> New machine
> Dual 3.6Ghz 64-bit Xeons dual channel scsi
> SCSI controller in each box is identical as is the drive configuration and
> file placement.
> I know this may not be a very clear view of the performance but I
> certainly expected more from the new server.
> We have a table tblMLOS which contains 392468 rows. This following script
> after repeated executions runs consistently at 9 seconds on the old server
> and 15-17 seconds on the new 64-bit machine. Are we missing something
> here? This just doesn't seem right.
> The table structure is very simple:
> create table tblMLOS
> (
> lngID int,
> lngSponsor int,
> lngSponsor2 int,
> lngSponsor3 int,
> strSponsorType varchar(20)
> )
> ---
> declare @.lngCount int
> declare @.lngID int
> declare curID cursor for
> select lngID from tblmlos
> set @.lngCount=0
> open curID
> fetch next from curID into @.lngID
> while @.@.fetch_status=0 begin
> set @.lngCount=@.lngCount+1
> fetch next from curID into @.lngID
> end
> close curID
> deallocate curID
> select @.lngCount
>
>|||This is not a production query. Just one of the many things we are trying
to see if there is any performance increase at all. So far every thing
we've tried is slower on the SQL 2005 box. I just picked this one cause it
is easy and straightforward.
"Simon Sabin" <SimonSabin@.noemal.noemail> wrote in message
news:Or6gZQ$YGHA.5004@.TK2MSFTNGP02.phx.gbl...
> 64 bit will not always be quicker, your code will be purely CPU bound ,
> and probably only use 1 cpu, the difference in CPU is not much.
> Not sure why you are not just doing
> select count(1) from lngID from tblmlos
> This probably will be quicker.
> --
> Simon Sabin
> SQL Server MVP
> http://sqljunkies.com/weblog/simons
> "Tim Greenwood" <tim_greenwood A-T yahoo D-O-T com> wrote in message
> news:eFa%23wF%23YGHA.3400@.TK2MSFTNGP02.phx.gbl...
>> This is comparing performance between two machines...the first is our
>> current SQL2000 server
>> Dual 3Ghz Xeons on dual channel scsi drives.
>> New machine
>> Dual 3.6Ghz 64-bit Xeons dual channel scsi
>> SCSI controller in each box is identical as is the drive configuration
>> and file placement.
>> I know this may not be a very clear view of the performance but I
>> certainly expected more from the new server.
>> We have a table tblMLOS which contains 392468 rows. This following
>> script after repeated executions runs consistently at 9 seconds on the
>> old server and 15-17 seconds on the new 64-bit machine. Are we missing
>> something here? This just doesn't seem right.
>> The table structure is very simple:
>> create table tblMLOS
>> (
>> lngID int,
>> lngSponsor int,
>> lngSponsor2 int,
>> lngSponsor3 int,
>> strSponsorType varchar(20)
>> )
>> ---
>> declare @.lngCount int
>> declare @.lngID int
>> declare curID cursor for
>> select lngID from tblmlos
>> set @.lngCount=0
>> open curID
>> fetch next from curID into @.lngID
>> while @.@.fetch_status=0 begin
>> set @.lngCount=@.lngCount+1
>> fetch next from curID into @.lngID
>> end
>> close curID
>> deallocate curID
>> select @.lngCount
>>
>|||I do see in the execution plan between the 2k and 2k5 that the 2k5 is doing
a Clustered Index Insert at every fetch and then a Clustered Index Scan
where as the 2k box is just doing the Scan. The lngID column is a clustered
index and the indexes on the 2k5 box have all been rebuilt with fullscan.
"Simon Sabin" <SimonSabin@.noemal.noemail> wrote in message
news:Or6gZQ$YGHA.5004@.TK2MSFTNGP02.phx.gbl...
> 64 bit will not always be quicker, your code will be purely CPU bound ,
> and probably only use 1 cpu, the difference in CPU is not much.
> Not sure why you are not just doing
> select count(1) from lngID from tblmlos
> This probably will be quicker.
> --
> Simon Sabin
> SQL Server MVP
> http://sqljunkies.com/weblog/simons
> "Tim Greenwood" <tim_greenwood A-T yahoo D-O-T com> wrote in message
> news:eFa%23wF%23YGHA.3400@.TK2MSFTNGP02.phx.gbl...
>> This is comparing performance between two machines...the first is our
>> current SQL2000 server
>> Dual 3Ghz Xeons on dual channel scsi drives.
>> New machine
>> Dual 3.6Ghz 64-bit Xeons dual channel scsi
>> SCSI controller in each box is identical as is the drive configuration
>> and file placement.
>> I know this may not be a very clear view of the performance but I
>> certainly expected more from the new server.
>> We have a table tblMLOS which contains 392468 rows. This following
>> script after repeated executions runs consistently at 9 seconds on the
>> old server and 15-17 seconds on the new 64-bit machine. Are we missing
>> something here? This just doesn't seem right.
>> The table structure is very simple:
>> create table tblMLOS
>> (
>> lngID int,
>> lngSponsor int,
>> lngSponsor2 int,
>> lngSponsor3 int,
>> strSponsorType varchar(20)
>> )
>> ---
>> declare @.lngCount int
>> declare @.lngID int
>> declare curID cursor for
>> select lngID from tblmlos
>> set @.lngCount=0
>> open curID
>> fetch next from curID into @.lngID
>> while @.@.fetch_status=0 begin
>> set @.lngCount=@.lngCount+1
>> fetch next from curID into @.lngID
>> end
>> close curID
>> deallocate curID
>> select @.lngCount
>>
>

First Connection to SQL Server 2000 is slow (takes 15 seconds)

I have a client machine running VS.Net 2003, using TCP/IP to connect to a
server running SQL Server 2000 Developer. The first time I connect to the
server it always takes 15 seconds. Subsequent work on the server is very
quick but that first 15 seconds is extremely painful. It doesn’t mater if I
perform a DA.Fill(DS) or a cmd.open(), it still takes 15 seconds. The delay
is the same if I run an application from within the IDE or from a build. I
read about similar problems being solved with upgrades to MDAC 2.6. However
the Client runs 2.8 and the server runs 2.7 so that resolution does not
appear to apply. My Client is the only machine that connects with SQL Server.
I have not always had this problem. Unfortunately, I can’t say what I did
that caused it, but the problem did not exist when I was running VS.Net 2003
and the Server was running MSDE 2000. Since then the following has occurred.
1.Downloaded and Installed but not using the MS Office interop stuff (Client)
2.Downloaded and Installed MDAC 2.8(Client)
3.Downloaded and Installed SQL Server 2000 Developer for Enterprise Mgr.
(Server)
Thank you in advance for your help.
Other items that may help:
I have an Access 2003 ADP on the client that uses the same SQL Server DB and
it also takes 15 seconds before displaying the table objects. However, if I
close the adp and reopen it within 15 seconds, the tables display
immediately. If I close the adp and wait longer than 15 seconds, it takes 15
seconds to display the tables. Once the tables are displayed, access to data
within any table is sub second.
I tried this with my .Net application. Same result. If I restart my
application within 15 seconds, then access to SQL Server is sub-second. If I
restart my application after 15 seconds, then it takes 15 seconds to connect.
I have another adp on the Server that points to the same SQL Server
database. It opens and displays the tables immediately.
Enterprise Manager runs on the Server. As I drill down the tree to
databases>Tables>TblX>Return all rows responds as quickly as I can click the
nodes etc. However, if I right click on the database (or any of the standard
DB’s (Master, Model, etc) and select properties, it takes 15 seconds the
first time.
Jim
Please refer to original. Sent duplicate in error. Sorry
"AdvanTouch" wrote:

> I have a client machine running VS.Net 2003, using TCP/IP to connect to a
> server running SQL Server 2000 Developer. The first time I connect to the
> server it always takes 15 seconds. Subsequent work on the server is very
> quick but that first 15 seconds is extremely painful. It doesn’t mater if I
> perform a DA.Fill(DS) or a cmd.open(), it still takes 15 seconds. The delay
> is the same if I run an application from within the IDE or from a build. I
> read about similar problems being solved with upgrades to MDAC 2.6. However
> the Client runs 2.8 and the server runs 2.7 so that resolution does not
> appear to apply. My Client is the only machine that connects with SQL Server.
> I have not always had this problem. Unfortunately, I can’t say what I did
> that caused it, but the problem did not exist when I was running VS.Net 2003
> and the Server was running MSDE 2000. Since then the following has occurred.
> 1.Downloaded and Installed but not using the MS Office interop stuff (Client)
> 2.Downloaded and Installed MDAC 2.8(Client)
> 3.Downloaded and Installed SQL Server 2000 Developer for Enterprise Mgr.
> (Server)
> Thank you in advance for your help.
> Other items that may help:
> I have an Access 2003 ADP on the client that uses the same SQL Server DB and
> it also takes 15 seconds before displaying the table objects. However, if I
> close the adp and reopen it within 15 seconds, the tables display
> immediately. If I close the adp and wait longer than 15 seconds, it takes 15
> seconds to display the tables. Once the tables are displayed, access to data
> within any table is sub second.
> I tried this with my .Net application. Same result. If I restart my
> application within 15 seconds, then access to SQL Server is sub-second. If I
> restart my application after 15 seconds, then it takes 15 seconds to connect.
> I have another adp on the Server that points to the same SQL Server
> database. It opens and displays the tables immediately.
> Enterprise Manager runs on the Server. As I drill down the tree to
> databases>Tables>TblX>Return all rows responds as quickly as I can click the
> nodes etc. However, if I right click on the database (or any of the standard
> DB’s (Master, Model, etc) and select properties, it takes 15 seconds the
> first time.
> --
> Jim

First Connection to SQL Server 2000 is slow (takes 15 seconds)

I have a client machine running VS.Net 2003, using TCP/IP to connect to a
server running SQL Server 2000 Developer. The first time I connect to the
server it always takes 15 seconds. Subsequent work on the server is very
quick but that first 15 seconds is extremely painful. It doesn’t mater if I
perform a DA.Fill(DS) or a cmd.open(), it still takes 15 seconds. The delay
is the same if I run an application from within the IDE or from a build. I
read about similar problems being solved with upgrades to MDAC 2.6. However
the Client runs 2.8 and the server runs 2.7 so that resolution does not
appear to apply. My Client is the only machine that connects with SQL Server.
I have not always had this problem. Unfortunately, I can’t say what I did
that caused it, but the problem did not exist when I was running VS.Net 2003
and the Server was running MSDE 2000.
Jim
PLease Refer to my original. Sent Duplicate in error. Sorry.
"AdvanTouch" wrote:

> I have a client machine running VS.Net 2003, using TCP/IP to connect to a
> server running SQL Server 2000 Developer. The first time I connect to the
> server it always takes 15 seconds. Subsequent work on the server is very
> quick but that first 15 seconds is extremely painful. It doesn’t mater if I
> perform a DA.Fill(DS) or a cmd.open(), it still takes 15 seconds. The delay
> is the same if I run an application from within the IDE or from a build. I
> read about similar problems being solved with upgrades to MDAC 2.6. However
> the Client runs 2.8 and the server runs 2.7 so that resolution does not
> appear to apply. My Client is the only machine that connects with SQL Server.
> I have not always had this problem. Unfortunately, I can’t say what I did
> that caused it, but the problem did not exist when I was running VS.Net 2003
> and the Server was running MSDE 2000.
> --
> Jim

First Connection to SQL Server 2000 is slow (takes 15 seconds)

I have a client machine running VS.Net 2003, using TCP/IP to connect to a
server running SQL Server 2000 Developer. The first time I connect to the
server it always takes 15 seconds. Subsequent work on the server is very
quick but that first 15 seconds is extremely painful. It doesn’t mater if I
perform a DA.Fill(DS) or a cmd.open(), it still takes 15 seconds. The delay
is the same if I run an application from within the IDE or from a build. I
read about similar problems being solved with upgrades to MDAC 2.6. However
the Client runs 2.8 and the server runs 2.7 so that resolution does not
appear to apply. My Client is the only machine that connects with SQL Server.
I have not always had this problem. Unfortunately, I can’t say what I did
that caused it, but the problem did not exist when I was running VS.Net 2003
and the Server was running MSDE 2000. Since then the following has occurred.
1.Downloaded and Installed but not using the MS Office interop stuff (Client)
2.Downloaded and Installed MDAC 2.8(Client)
3.Downloaded and Installed SQL Server 2000 Developer for Enterprise Mgr.
(Server)
Thank you in advance for your help.
Other items that may help:
I have an Access 2003 ADP on the client that uses the same SQL Server DB and
it also takes 15 seconds before displaying the table objects. However, if I
close the adp and reopen it within 15 seconds, the tables display
immediately. If I close the adp and wait longer than 15 seconds, it takes 15
seconds to display the tables. Once the tables are displayed, access to data
within any table is sub second.
I tried this with my .Net application. Same result. If I restart my
application within 15 seconds, then access to SQL Server is sub-second. If I
restart my application after 15 seconds, then it takes 15 seconds to connect.
I have another adp on the Server that points to the same SQL Server
database. It opens and displays the tables immediately.
Enterprise Manager runs on the Server. As I drill down the tree to
databases>Tables>TblX>Return all rows responds as quickly as I can click the
nodes etc. However, if I right click on the database (or any of the standard
DB’s (Master, Model, etc) and select properties, it takes 15 seconds the
first time.
Jim
PLEASE REFER TO MY ORIGINAL. I submitted 4. The first 3 came back with
Posting Error. Sorry.
"AdvanTouch" wrote:

> I have a client machine running VS.Net 2003, using TCP/IP to connect to a
> server running SQL Server 2000 Developer. The first time I connect to the
> server it always takes 15 seconds. Subsequent work on the server is very
> quick but that first 15 seconds is extremely painful. It doesn’t mater if I
> perform a DA.Fill(DS) or a cmd.open(), it still takes 15 seconds. The delay
> is the same if I run an application from within the IDE or from a build. I
> read about similar problems being solved with upgrades to MDAC 2.6. However
> the Client runs 2.8 and the server runs 2.7 so that resolution does not
> appear to apply. My Client is the only machine that connects with SQL Server.
> I have not always had this problem. Unfortunately, I can’t say what I did
> that caused it, but the problem did not exist when I was running VS.Net 2003
> and the Server was running MSDE 2000. Since then the following has occurred.
> 1.Downloaded and Installed but not using the MS Office interop stuff (Client)
> 2.Downloaded and Installed MDAC 2.8(Client)
> 3.Downloaded and Installed SQL Server 2000 Developer for Enterprise Mgr.
> (Server)
> Thank you in advance for your help.
> Other items that may help:
> I have an Access 2003 ADP on the client that uses the same SQL Server DB and
> it also takes 15 seconds before displaying the table objects. However, if I
> close the adp and reopen it within 15 seconds, the tables display
> immediately. If I close the adp and wait longer than 15 seconds, it takes 15
> seconds to display the tables. Once the tables are displayed, access to data
> within any table is sub second.
> I tried this with my .Net application. Same result. If I restart my
> application within 15 seconds, then access to SQL Server is sub-second. If I
> restart my application after 15 seconds, then it takes 15 seconds to connect.
> I have another adp on the Server that points to the same SQL Server
> database. It opens and displays the tables immediately.
> Enterprise Manager runs on the Server. As I drill down the tree to
> databases>Tables>TblX>Return all rows responds as quickly as I can click the
> nodes etc. However, if I right click on the database (or any of the standard
> DB’s (Master, Model, etc) and select properties, it takes 15 seconds the
> first time.
> --
> Jim

First Connection to SQL Server 2000 is slow (takes 15 seconds)

I have a client machine running VS.Net 2003, using TCP/IP to connect to a
server running SQL Server 2000 Developer. The first time I connect to the
server it always takes 15 seconds. Subsequent work on the server is very
quick but that first 15 seconds is extremely painful. It doesn’t mater if
I
perform a DA.Fill(DS) or a cmd.open(), it still takes 15 seconds. The delay
is the same if I run an application from within the IDE or from a build. I
read about similar problems being solved with upgrades to MDAC 2.6. However
the Client runs 2.8 and the server runs 2.7 so that resolution does not
appear to apply. My Client is the only machine that connects with SQL Server
.
I have not always had this problem. Unfortunately, I can’t say what I did
that caused it, but the problem did not exist when I was running VS.Net 2003
and the Server was running MSDE 2000. Since then the following has occurred.
1. Downloaded and Installed but not using the MS Office interop stuff (Clien
t)
2. Downloaded and Installed MDAC 2.8 (Client)
3. Downloaded and Installed SQL Server 2000 Developer for Enterprise Mgr.
(Server)
Thank you in advance for your help.
Other items that may help:
I have an Access 2003 ADP on the client that uses the same SQL Server DB and
it also takes 15 seconds before displaying the table objects. However, if I
close the adp and reopen it within 15 seconds, the tables display
immediately. If I close the adp and wait longer than 15 seconds, it takes 15
seconds to display the tables. Once the tables are displayed, access to data
within any table is sub second.
I tried this with my .Net application. Same result. If I restart my
application within 15 seconds, then access to SQL Server is sub-second. If I
restart my application after 15 seconds, then it takes 15 seconds to connect
.
I have another adp on the Server that points to the same SQL Server
database. It opens and displays the tables immediately.
Enterprise Manager runs on the Server. As I drill down the tree to
databases>Tables>TblX>Return all rows responds as quickly as I can click the
nodes etc. However, if I right click on the database (or any of the standard
DB’s (Master, Model, etc) and select properties, it takes 15 seconds the
first time.
JimPLEASE REFER TO MY ORIGINAL. I submitted 4. The first 3 came back with
Posting Error. Sorry.
"AdvanTouch" wrote:

> I have a client machine running VS.Net 2003, using TCP/IP to connect to a
> server running SQL Server 2000 Developer. The first time I connect to the
> server it always takes 15 seconds. Subsequent work on the server is very
> quick but that first 15 seconds is extremely painful. It doesn’t mater i
f I
> perform a DA.Fill(DS) or a cmd.open(), it still takes 15 seconds. The dela
y
> is the same if I run an application from within the IDE or from a build. I
> read about similar problems being solved with upgrades to MDAC 2.6. Howeve
r
> the Client runs 2.8 and the server runs 2.7 so that resolution does not
> appear to apply. My Client is the only machine that connects with SQL Serv
er.
> I have not always had this problem. Unfortunately, I can’t say what I di
d
> that caused it, but the problem did not exist when I was running VS.Net 20
03
> and the Server was running MSDE 2000. Since then the following has occurre
d.
> 1. Downloaded and Installed but not using the MS Office interop stuff (Cli
ent)
> 2. Downloaded and Installed MDAC 2.8 (Client)
> 3. Downloaded and Installed SQL Server 2000 Developer for Enterprise Mgr.
> (Server)
> Thank you in advance for your help.
> Other items that may help:
> I have an Access 2003 ADP on the client that uses the same SQL Server DB a
nd
> it also takes 15 seconds before displaying the table objects. However, if
I
> close the adp and reopen it within 15 seconds, the tables display
> immediately. If I close the adp and wait longer than 15 seconds, it takes
15
> seconds to display the tables. Once the tables are displayed, access to da
ta
> within any table is sub second.
> I tried this with my .Net application. Same result. If I restart my
> application within 15 seconds, then access to SQL Server is sub-second. If
I
> restart my application after 15 seconds, then it takes 15 seconds to conne
ct.
> I have another adp on the Server that points to the same SQL Server
> database. It opens and displays the tables immediately.
> Enterprise Manager runs on the Server. As I drill down the tree to
> databases>Tables>TblX>Return all rows responds as quickly as I can click t
he
> nodes etc. However, if I right click on the database (or any of the standa
rd
> DB’s (Master, Model, etc) and select properties, it takes 15 seconds the
> first time.
> --
> Jim

First Connection to SQL Server 2000 is slow (takes 15 seconds)

I have a client machine running VS.Net 2003, using TCP/IP to connect to a
server running SQL Server 2000 Developer. The first time I connect to the
server it always takes 15 seconds. Subsequent work on the server is very
quick but that first 15 seconds is extremely painful. It doesn’t mater if
I
perform a DA.Fill(DS) or a cmd.open(), it still takes 15 seconds. The delay
is the same if I run an application from within the IDE or from a build. I
read about similar problems being solved with upgrades to MDAC 2.6. However
the Client runs 2.8 and the server runs 2.7 so that resolution does not
appear to apply. My Client is the only machine that connects with SQL Server
.
I have not always had this problem. Unfortunately, I can’t say what I did
that caused it, but the problem did not exist when I was running VS.Net 2003
and the Server was running MSDE 2000.
--
JimPLease Refer to my original. Sent Duplicate in error. Sorry.
"AdvanTouch" wrote:

> I have a client machine running VS.Net 2003, using TCP/IP to connect to a
> server running SQL Server 2000 Developer. The first time I connect to the
> server it always takes 15 seconds. Subsequent work on the server is very
> quick but that first 15 seconds is extremely painful. It doesn’t mater i
f I
> perform a DA.Fill(DS) or a cmd.open(), it still takes 15 seconds. The dela
y
> is the same if I run an application from within the IDE or from a build. I
> read about similar problems being solved with upgrades to MDAC 2.6. Howeve
r
> the Client runs 2.8 and the server runs 2.7 so that resolution does not
> appear to apply. My Client is the only machine that connects with SQL Serv
er.
> I have not always had this problem. Unfortunately, I can’t say what I di
d
> that caused it, but the problem did not exist when I was running VS.Net 20
03
> and the Server was running MSDE 2000.
> --
> Jim

First attempt to connect fails

I have a C# application that connects to a SQL Server Express 2005 instance. One of the testers here shuts his machine down every night and first thing in the morning when he fires up the application it fails to connect. If he tries to open it again right after that it connects. What would the failed attempt do that would fix the instance?

hi,

what is the reported exception?

regards

|||

If the C# application is using User Instances, the problem is likely a timeout. Check the connection string, if it is specifiying User Instance = TRUE, then add 'Connection Timeout=60' and the problem will likely go away. The issue is that a User Instance has to be started when the application is started and depending on hardware, it can take a bit longer than the default connection time out. Once it has started, it will hang around for 60 minutes after the last connection is dropped, so the second time you run the applciation, the User Instance is running and the connection can be made within the default timeout setting.

Mike

|||

The connection string doesn't have user instance in it. Should I just not be using user instances?

|||YOu don′t have to, depending on the machine and the workload it also could be that the database is closed again and will have to open after reconnecting. The autoclose option can be either turned off (turned on by default for Express instances) or the connection timeout can be increased as Mike pointed out.

Jens K. Suessmeyer.

http://www.sqlserver2005.de

Firewall

We have several clients using one application on their Laptop to connect to Sql Server using either the dial-up or vpn client on their machine.Each client is behind the firewall.The query timeout on the sql server has been set to 0. Six out of 10 cases the application works fine,but when you let some screen open on the client's machine without any activity for may be 5 minutes(the application screen using sql server),come back and try to save the changes made by you and It's giving us the "Connection failure Error".
The same thing is not happeing over the LAN.

Any help in this matter is greatly appriciated.Can you modify the application to support disconnected recordsets and just update the changes as a batch ? Does it timeout on all of the machines outside of the firewall after the 5 minute mark ? Are you using connection pooling ?|||What is generating the error "Connection Failure" ? Is this the exact error message ?|||[DBNETLIB][ConnectionRead (recv()).]General network error. Check your network documentation.|||Are you able to access anything else behind the firewall - or do you lose all network access to the network behind the firewall ?|||Last time we were checking the connection behaviour in the Sql Server 2000 by using the sp_who command line and after some time(may be 6-8 minutes)we realized that there are no active connections between the Client and the Server.We think that the firewall is disconnecting the client with no activity after 10 minutes.Still searching|||We are using the CISCO firewall

Firefox vs IE, make RS always open in IE?

I use Firefox as my default browser on my development machine for
RS2005 with SS2005.
I solved the authentication problem by setting IE to Tools, Security,
Intranet to User Authentication, Logon, all the way down at the bottom
of the list to Automatic logon with current user name and password.
BUT I still get the rendering errors...reports don't look right, etc.,
I have not seen any fixes in this list.
Is it possible for me to make the Reports and ReportServer sites on my
dev box to always open in IE and not in Firefox'
Thank you, TomI also use Firefox, I use the IE View extension to always view in IE.
Unfortunatelly for me our web app will also support Firefox and the reports
go along with that. Microsoft RS does not support Firefox and I haven't
seen any thing that states that they plan to. I think there are two main
issues, the Chart height and table column widths. We don't have the chart
height issue because we use Dundas and they don't appear to have the same
problem...which is kind of interesting since they also write the native
chart in RS. They are forced into using the custom control set of
interfaces which means they have image quality issues due to the limitations
in RS, but for this matter they are better. The other problem we have been
able to fix with the empty wide textbox scattered above tables. This idea
comes from the notes from Jon Galloway in the link below.
Thanks,
Steve MunLeeuw
Here are my notes:
Hi Max,
Thank you for using MSDN Managed Newsgroup Support.
I understand that your report does not show the right format in Firefox
browser.
Unfortunately, Microsoft does not support any browsers other than Internet
Explorer. All the Render Extension in Reporting Services are developed
against IE. So there is no way to guarantee that Reporting Services will
perform well with other browsers.
Please understand that we don't have an environment to reproduce and
troubleshoot your issue, but please feel free to involve me during the
process of contacting third-party support, I am glad to provide any
information.
Sincerely,
Wei Lu
Microsoft Online Community Support
/* Fix report IFRAME height for Firefox */
.DocMapAndReportFrame
{
min-height: 860px;
}
--removed .css fix from dev
machinehttp://weblogs.asp.net/jgalloway/archive/2006/09/01/SQL-Reporting-Services-_2D00_-CSS-fix-for-Firefox.aspx
"tlyczko" <tlyczko@.gmail.com> wrote in message
news:1161702061.967677.79830@.e3g2000cwe.googlegroups.com...
>I use Firefox as my default browser on my development machine for
> RS2005 with SS2005.
> I solved the authentication problem by setting IE to Tools, Security,
> Intranet to User Authentication, Logon, all the way down at the bottom
> of the list to Automatic logon with current user name and password.
> BUT I still get the rendering errors...reports don't look right, etc.,
> I have not seen any fixes in this list.
> Is it possible for me to make the Reports and ReportServer sites on my
> dev box to always open in IE and not in Firefox'
> Thank you, Tom
>