Any help here???

[Guest]

Have Visual Studio.NET installed on MS 2000 Professional OS laptop. No issue
ever with web development and SQL connections.
Purchased new laptop with XP Professional SP2!!!!!!!! & Visual Studio.NET
installed.
Nothing but headaches. Continually getting
System.Data.SqlClient.SqlException : Timeout expired message - The timeout
period elapsed prior to completion of the operation or the server is not
responding.
Can anyone help with this??? Why error's with LATER versions of your
software?

 

[TJS]

seems like the sql server is not responding,. doesn't seem like it has
anything to do with the OS.

Check to make sure SQL server is running and name of the server is same as
in connection code

 

[Guest]

SQL server is running. I can test with my other laptop - 2K version. All is
well there. It does appear to be latest OS - I've also reviewed other posts
by others users - but noone has answered questions.

Futher, everything fine on SQL - running for every app - again, including
other 2K OS laptop - and in development mode there with no problem.
Basically the new XP SP2 has issues - but I'm not sure where to fix.

 

[PB]

<<Basically the new XP SP2 has issues >>

Maybe so, but not necessarily relevant to your errors. I migrated from 2k to
XP SP2 with no issues at all - and did so on multiple development machines
(laptop, desktop). Many other developers in this group report using XP SP2
with NO problems.

As long as you are concluding that XP SP2 is "the problem" then it may take
you more time to figure out what is really causing "the problem". There are
potentially many many differences between your 2k machine and your XP
machine - the OS is just one of those many differences.

Maybe we could help you more if you were to describe specifically what your
setup is. Do you have SQL Server 2000 installed on the local machine? When
you say you can test with other laptop - 2K version - are you saying that
that machine is connecting to the XP machine and choking? If os, then XP'
firewall may need to be opened up a bit. No one can reasonably suggest you
look at the firewall NOR ANY other potential configuration issues without
knowing more about your specific setup. If it all works on your 2K machine
(everything is installed locally) but not on the XP machine (with everthing
installed locally), then its time to look at similarities and differences
between specific configuration settings - and not just conclude that the
OS - which is the most unlikely culprit here - is "the" problem.

Help us help you - and we will.

 

[WJ]

By default, XP pro. Service Pack# 2 locks down your system. You will have to
do the followings:

1. Install IIS-5 and enable it.
2. Check PFW (disable it first, then gradually block certain ports).
3. Install .NetFW 1.1 and hotfixes (sp2 should have done that for you
already).
4. Enable ASPNet account if it is not.
5. Check all WinXP Services.
6. Install VS.Net.
7. Grant ASPNET account to SQL Server if you plan Windows Integrated and
allow anonymous.

I am running IBM LapTop with service Pack 2 on XP Pro. edition, SQL Server
developer edition with VS.Net 2k3 and I have no problem at all.

John

 

[Guest]

I almost was ready to look @ working with UNIX environment - but that's
statement only out of frustration. First, THANK YOU for responding. Next,
I'll answer all your questions too - and hopefully we can get solution here
to fix this for our development environment.

1) SQL 200 Server is not local - it's on separate server all by itself. I
have two laptops - both with Visual Studio.NET that I've installed. MDAC
components 2.6 is what is on laptop I believe. I've never had connection
issue to SQL databases here - very rare to get timeouts.
2) I've also installed Visual Studio.NET on 2000 server for development
server - and not issue there. MDAC 2.6 I believe is installed there. I've
installed IIS and just about everything here - and not issue. Never SQL
timeouts.
3) MDAC 2.8 is installed on 2nd laptop with Windows XP SP2. I've also
installed Visual Studio.NET here (I believe this is default with OS).
Everything works great but SQL doesn't connect & popup issue - BUT for now
lets ignore popup issue. Once in a blue-moon I can connect to SQL server -
but 98% of time it times out or simply doesn't connect. I have 20 second
default for connection string (changed to 30, 60, etc... and doesn't help) as
on Windows 2000 OS laptop. I agree there are many differences with both OS's
- DLL's are one variation, MDAC is most obvious that I see @ this time. I've
downloaded Microsoft Product Support Reporting Tools - to review what's here
too - after researching on your knowledge base.
4) Currently, I'm going to formulate more information - but what's best way
to give you what you need. My initial objective is NOT to conclude OS - but
trust me - all that's been done here was to install SP2 or upgrade of XP from
Microsoft. Next, I've completed the install of Visual Studio.NET like I've
done for 3 other computers - without issue. Again - MDAC - I've research
this myself - since it's relavent to SQL connect objects.

What would you need from me first - to check/review
similarities/dissimilarities.

Thank you kindly.

 

[PB]

Well, for starters, I believe MDAC is unnecessary for .NET applications - as
ADO.NET has its own SQL Server provider for data access. The only reason I
could think of off hand for installing MDAC is for any old COM applications
that may need it.

So, when you say you are connecting to SQL Server, are you doing so from an
ASP.NET Web application? or from some COM-based application? If from .NET -
then what does your connection string and connection object look like? Are
you defining them in code? If so, lets have a look.

Also, which version of Visual Studio .NET? 2003? As long as you are setting
up a new development environment for new projects that were not based on any
prior version of .NET, then you really should be using .NET Framework 1.1
(which installs with VS.NET 2003).

I personally have worked extensively with many prior versions of MDAC - and
honestly since switching to .NET development I've never had to deal with
MDAC (and good riddance!).

Finally (for now), this news group is run by Microsoft, but most of the
people who are posting here are NOT Microsoft employees. We are mostly
people just like yourself figuring out how to make all this stuff work and
helping each other out.

-HTH

 

[Guest]

Note: 2) - what I mean here is I have another server (not SQL 2000 server)
that is development server with Visual Studio.NET. IIS installed here too.
No problems.

Problem is just XP SP2 laptop as identified above. Again, I'll try
reinstalling IIS again - I believe it's 5.1 on the XP Laptop - but 5.0 on
Windows 2000 Pro Laptop - that's the only other difference I see - but I took
latest from MS.

 

[Guest]

Doing so from ASP.NET web application. Using Visual Studio.NET 2003 -
Version 7.1.3088. Microsoft .NET Framework 1.1 (1.1.4322 SP1) it says for XP
SP2 OS. Using Visual Studio.NET 2003 - Version 7.1.3088. Microsoft .NET
Framework 1.1 (1.1.4322) NO SP1 for 2000 Pro OS.

I think MDAC Applies in this instance. @ Least as I understand it's the
core for SQL, Ole, and ODBC connections.

 

[Guest]

Connect String -------------

Server=<server name>;database=<database
name>;uid=<uid>;pwd=<password>;connect timeout=30;pooling=true

Never problem -

 

[PB]

<<I think MDAC Applies in this instance>>

No way. ADO.NET has an entirely new SQL data provider. OLE is old-school
COM, ODBC is totally unnecessary here and even undesirable as ADO.NET's SQL
data provider is optimized for SQL Server. Show us how you are trying to
connect. Show us your code.

I'd sure hate to be going off into left field here - all I'm thinking is
that you are installing MDAC which is totally unnecessary. Put another way,
I've never had any SQL Server connectivity problems since I've switch to
..NET - and I've never installed MDAC or tried to use ODBC. Furthermore, I've
never even heard of anyone trying to install or use MDAC from a .NET
application when trying to connect to SQL Server.

ADO.NET is not simply the latest version of the original ADO classic (which
necessitated the installation of MDAC for COM applications). ADO.NET is a
whole new thing.

-HTH

 

[PB]

So, are you using the System.Data.SqlClient namespace and its SqlCommand and
SqlConnection objects?

 

[Guest]

I'm using ADO.NET - specific classes used were
1) System.Data.SqlClient - connection to Microsoft SQL Server - I also have
version 08.00.0384 of SQL Server 2000
2) System.Data.OleDb - connection to other Access Databases
3) System.Data.Odbc - used this likewise.
For discussion, like to simply stay with ADO.NET - System.Data.SqlClient.

Next, I apologize for discussion concerning MDAC - I was 100% sure how this
was used - but in past - system would advise me I needed latest during
debugging. I've also researched article from Microsoft saying when you
troubleshoot SQL Server connectivity issues - you should investigate the MDAC
version on the client, not on the server. Article was MDAC Technical Article
Pg 3 - Installation Versions and SQL Server Versions. I just thought it
might apply there.

Finally, since issue now is completely understood as ADO.NET - SQL provider,
I'd like to move to next issue. What could be causing no connects during
open operation?

Thanks always,

 

[Guest]

I'm using ADO.NET - specific classes used were
1) System.Data.SqlClient - connection to Microsoft SQL Server - I also have
version 08.00.0384 of SQL Server 2000
2) System.Data.OleDb - connection to other Access Databases
3) System.Data.Odbc - used this likewise.
For discussion, like to simply stay with ADO.NET - System.Data.SqlClient.

Next, I apologize for discussion concerning MDAC - I was NOT 100% sure how
this
was used - but in past - system @ one time advises me I needed latest
release during
debugging. I've also researched article from Microsoft saying when you
troubleshoot SQL Server connectivity issues - you should investigate the MDAC
version on the client, not on the server. Article was MDAC Technical Article
Pg 3 - Installation Versions and SQL Server Versions. I just thought it
might apply there.

Finally, since issue now is completely understood as ADO.NET - SQL provider,
I'd like to move to next issue. What could be causing no connects during
open operation?

Thanks always,

 

[PB]

If you are having odd connectivity issues (which IMHO you are having) then
start looking for things that are non standard (like having MDAC installed).
AFAIK you cannot uninstall MDAC once its installed. So rather than
troubleshooting a junked up computer you might be far better off in the long
run by starting all over from scratch and installing only what's necessary.
Format your drive, do a new/clean install of XP, and go from there. If you
keep things simple and only install and use what is recommended, you will
likely not have such weird issues. Before you jump gun and claim XP is
screwing up, start with basic network connectivity: can you PING your SQL
Server? Ping by IP address? Ping by URL? Your issues may have nothing to do
with ADO.NET. Start with the basics and work up from there.

If after cleaning up your computer you are still having exotic issues, you
might want to post a new question in an ADO.NET news group. Your issues
apparently have nothing to do with ASP.NET, XP, nor SP2.

Good Luck.

 

[Guest]

I did ping - simply slipped my mind. I've noticed 2 ports on SQL server.
First port - seems to tie up occassionally. I decided to use 2nd port - it's
not used at all - dedicated soley for my purposes - and never issues. I
connect NOW always. Only concern I have is simply 2000 OS setup - must have
retry built in - whereas XP SP2 - might not - I never timeout on 2000 / but
98% of time did on XP with 1st port. I have also now a system solution to
what's presented here (given thought to what we have in our configuration and
I will change things when connecting to SQL - i.e., past policy by others).

Finally - I wasn't going to reformat, reload, etc... the drive. That's like
saying I mind as well work with Unix. But for the most part - you were very
helpful with the "ping" suggestion. The most obvious was not the most
obvious for me - but when I looked in detail, I saw issues.

Tnks.