old sql2k5 folder: windows

Showing posts with label windows. Show all posts

Friday, March 30, 2012

One node Cluster for SQL 2005

Hi anyone know if you can cluster sql on a one node cluster in Windows 2003 ?
Regards Craig
Yes you can. You can even cluster SQL 2005 in Virtual Server with two
nodes, but it takes a bit of work.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Craig Gibb" <Craig Gibb@.discussions.microsoft.com> wrote in message
news:E4E75A9E-46BC-4DB4-9D22-B5862BBAFBF1@.microsoft.com...
> Hi anyone know if you can cluster sql on a one node cluster in Windows
> 2003 ?
> Regards Craig
>
|||Hi thanks for the info Geoff just now iam having a problem with DTC and
windows 2003 sp1 i thin there is COM + rollup package for the problem,
but i can′t find it anywhere KB 897667. MS support is closed here and i
would really like to install it this evening any ideas ?
Regards Craig
"Geoff N. Hiten" wrote:

> Yes you can. You can even cluster SQL 2005 in Virtual Server with two
> nodes, but it takes a bit of work.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
> "Craig Gibb" <Craig Gibb@.discussions.microsoft.com> wrote in message
> news:E4E75A9E-46BC-4DB4-9D22-B5862BBAFBF1@.microsoft.com...
>
>
|||Here is what I usually have to do with DTC on a Windows 2003 Server.
HOWTO: Enable DTC Between Web Servers and SQL Servers Running Windows Server
2003
http://support.microsoft.com/kb/555017/en-us
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Craig Gibb" <CraigGibb@.discussions.microsoft.com> wrote in message
news:304D6E36-D457-4FDB-A46D-D3941CA3DF86@.microsoft.com...[vbcol=seagreen]
> Hi thanks for the info Geoff just now iam having a problem with DTC and
> windows 2003 sp1 i thin there is COM + rollup package for the problem,
> but i cant find it anywhere KB 897667. MS support is closed here and i
> would really like to install it this evening any ideas ?
> Regards Craig
> "Geoff N. Hiten" wrote:

One ms sql server 2000 instance blocks the other (thru a dts-job)

Hello,

we use two instances of the ms sql server 2000 (Version: 8.00.760) on a
4 processor windows 2000 (sp 4) machine.
A dts-packet on one instance completly blocks the work on the other
instance. Both instances have 2 dedicated processors. The two
processors of the blocked instance are in idle states.
How is this possible? Has someone had the same behavior of the sql
server and found a solution for this problem?

Thanks in advance for answers

Jrgen Simonsen(juergen.simonsen@.web.de) writes:
> we use two instances of the ms sql server 2000 (Version: 8.00.760) on a
> 4 processor windows 2000 (sp 4) machine.
> A dts-packet on one instance completly blocks the work on the other
> instance. Both instances have 2 dedicated processors. The two
> processors of the blocked instance are in idle states.
> How is this possible? Has someone had the same behavior of the sql
> server and found a solution for this problem?

Have you tried to access that blocked instance, to see if it is possible
to run queries on it? Have you checked the SQL Server error log for the
blocked instance?

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

One more connection problem-Security Issue

My company gave me their old Windows 2000 server. I installed my
database on it and the ODBC connection works perfectly on the server.
When I go to my client machine I go the the ODBC Connections in it and
it fails. It refuses connections and will not reply to pings. It is not
a network issue, as I can telnet to the server just fine. It's strictly
a security issue. I just have no clue where to look. Any suggestions
would be appreciated. ThanksCurt (myemail@.nowehere.com) writes:

Quote:

Originally Posted by

Which version of SQL Server?

If you are using SQL 2005, you need to enable remote connections, as by
default Express and Developer Editon only accepts local connections. You
can use the Surface Area Configuration tool for this.

Also, if you are using SQL Express, make sure that SQL Broswer is running,
so that the named instance can be found.

If you are using SQL 2000, I would look in the Server Network Utility
to see which protcols that are installed.

Monday, March 26, 2012

Once a week or once a month

Running a SQL 7 system on a Windows 2000 server using Access 2000 on client
machines as a front end. System administrator currently reboots the server
once a month. Yesterday we had some weird thing with the database where
users were getting ODBC errors when trying to access it. Rebooted the
server, everything was fine. Suggested to the sa that he reboot the server
once a week. He said he already does it once a month, and that's sufficient.
My POV is that: a) doing it once a week might prevent situations such as the
one yesterday; b) even without situations like the one yesterday,
performance may be degrading over the course of the month, without our being
aware of it, and rebooting once a week might help performance.
Any thoughts on this?
Thanks!
Neil
Just because the reboot fixed the issue doesn't mean that a preventative
reboot will stop it from occuring.
A reboot might not have been needed to resolve the issue in the first place.
Possibly a configuration change
or bouncing a service could have resolved it. My advice is to spend some
time researching the issue and if
you cant find a way to resolve it then find a way to detect it and have it
perform the least intrusive form of corrective action.
-Mike
"Neil" <nospam@.nospam.net> wrote in message
news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy. net...
> Running a SQL 7 system on a Windows 2000 server using Access 2000 on
> client machines as a front end. System administrator currently reboots the
> server once a month. Yesterday we had some weird thing with the database
> where users were getting ODBC errors when trying to access it. Rebooted
> the server, everything was fine. Suggested to the sa that he reboot the
> server once a week. He said he already does it once a month, and that's
> sufficient.
> My POV is that: a) doing it once a week might prevent situations such as
> the one yesterday; b) even without situations like the one yesterday,
> performance may be degrading over the course of the month, without our
> being aware of it, and rebooting once a week might help performance.
> Any thoughts on this?
> Thanks!
> Neil
>
|||Why does he reboot at all?
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau
"Neil" <nospam@.nospam.net> wrote in message
news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy. net...
Running a SQL 7 system on a Windows 2000 server using Access 2000 on client
machines as a front end. System administrator currently reboots the server
once a month. Yesterday we had some weird thing with the database where
users were getting ODBC errors when trying to access it. Rebooted the
server, everything was fine. Suggested to the sa that he reboot the server
once a week. He said he already does it once a month, and that's sufficient.
My POV is that: a) doing it once a week might prevent situations such as the
one yesterday; b) even without situations like the one yesterday,
performance may be degrading over the course of the month, without our being
aware of it, and rebooting once a week might help performance.
Any thoughts on this?
Thanks!
Neil
|||OK, that's fine. But my POV is that rebooting in general, and resetting the
system memory, is a good thing to do. I take it that you disagree?
"Michael Abair" <mabair@.autotask.com> wrote in message
news:eTxBHcEOIHA.2064@.TK2MSFTNGP06.phx.gbl...
> Just because the reboot fixed the issue doesn't mean that a preventative
> reboot will stop it from occuring.
> A reboot might not have been needed to resolve the issue in the first
> place. Possibly a configuration change
> or bouncing a service could have resolved it. My advice is to spend some
> time researching the issue and if
> you cant find a way to resolve it then find a way to detect it and have it
> perform the least intrusive form of corrective action.
> -Mike
> "Neil" <nospam@.nospam.net> wrote in message
> news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy. net...
>
|||See my response to Michael in this thread.
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:%23LFLkcEOIHA.4196@.TK2MSFTNGP04.phx.gbl...
> Why does he reboot at all?
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
> SQL Server MVP
> Toronto, ON Canada
> https://mvp.support.microsoft.com/profile/Tom.Moreau
>
> "Neil" <nospam@.nospam.net> wrote in message
> news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy. net...
> Running a SQL 7 system on a Windows 2000 server using Access 2000 on
> client
> machines as a front end. System administrator currently reboots the server
> once a month. Yesterday we had some weird thing with the database where
> users were getting ODBC errors when trying to access it. Rebooted the
> server, everything was fine. Suggested to the sa that he reboot the server
> once a week. He said he already does it once a month, and that's
> sufficient.
> My POV is that: a) doing it once a week might prevent situations such as
> the
> one yesterday; b) even without situations like the one yesterday,
> performance may be degrading over the course of the month, without our
> being
> aware of it, and rebooting once a week might help performance.
> Any thoughts on this?
> Thanks!
> Neil
>
|||Neil (nospam@.nospam.net) writes:
> OK, that's fine. But my POV is that rebooting in general, and resetting
> the system memory, is a good thing to do. I take it that you disagree?
I do. Unless there is some known issues, there is rarely any reason to
reboot SQL Server regularly. OK, so you have SQL 7, and this version is a
bit old. Nevertheless, it has the same basic architecture as subsequent
SQL Server versions. The predecessors 6.x were less stable. (In 6.0 there
was a bug that compelled you to restart the bug about every 48th day.
There was some counter somewhere that wrapped around after 49 days.)
As for rebooting helping performance, it may be the other way round.
When you reboot, the entire plan cache will be thrown away, and until
the plan has built up, the server will spend more time compiling. But
that's the only thing. Say that you have a table with date column,
into which the current date is typically inserted, and queries against
this table are typically for the recent days. If the query is a stored
procedure or is parameterised, the plan will be built using that date.
But if statistics are out of date, the estimates will be wrong, and you
may get a bad plan. Had you never restarted the server, the old good
plan would have remained in cache.
But, OK, the reverse can happen: the old plan was bad, but statistics
have been updated recently, so now you get a good plan.
As for your problem the other day, you did not include any error message,
but I would guess that it was a temporary network problem, and it would
have gone away even if you had not restarted SQL Server.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
|||Why does the system memory need to be reset? I've seen SQL Servers stay up
for months and not need a reboot. That's what High Availability is all
about.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau
"Neil" <nospam@.nospam.net> wrote in message
news:NQZ5j.69213$RX.4340@.newssvr11.news.prodigy.ne t...
OK, that's fine. But my POV is that rebooting in general, and resetting the
system memory, is a good thing to do. I take it that you disagree?
"Michael Abair" <mabair@.autotask.com> wrote in message
news:eTxBHcEOIHA.2064@.TK2MSFTNGP06.phx.gbl...
> Just because the reboot fixed the issue doesn't mean that a preventative
> reboot will stop it from occuring.
> A reboot might not have been needed to resolve the issue in the first
> place. Possibly a configuration change
> or bouncing a service could have resolved it. My advice is to spend some
> time researching the issue and if
> you cant find a way to resolve it then find a way to detect it and have it
> perform the least intrusive form of corrective action.
> -Mike
> "Neil" <nospam@.nospam.net> wrote in message
> news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy. net...
>
|||"Neil" <nospam@.nospam.net> wrote in message
news:NQZ5j.69213$RX.4340@.newssvr11.news.prodigy.ne t...
> OK, that's fine. But my POV is that rebooting in general, and resetting
> the system memory, is a good thing to do. I take it that you disagree?
>
Yes. I disagree.
I've run systems with uptimes measured in years.
I see no value in rebooting a correctly setup system.

> "Michael Abair" <mabair@.autotask.com> wrote in message
> news:eTxBHcEOIHA.2064@.TK2MSFTNGP06.phx.gbl...
>
|||"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns99FEEDF6C864Yazorman@.127.0.0.1...
> Neil (nospam@.nospam.net) writes:
> I do. Unless there is some known issues, there is rarely any reason to
> reboot SQL Server regularly. OK, so you have SQL 7, and this version is a
> bit old. Nevertheless, it has the same basic architecture as subsequent
> SQL Server versions. The predecessors 6.x were less stable. (In 6.0 there
> was a bug that compelled you to restart the bug about every 48th day.
> There was some counter somewhere that wrapped around after 49 days.)
> As for rebooting helping performance, it may be the other way round.
> When you reboot, the entire plan cache will be thrown away, and until
> the plan has built up, the server will spend more time compiling. But
> that's the only thing. Say that you have a table with date column,
> into which the current date is typically inserted, and queries against
> this table are typically for the recent days. If the query is a stored
> procedure or is parameterised, the plan will be built using that date.
> But if statistics are out of date, the estimates will be wrong, and you
> may get a bad plan. Had you never restarted the server, the old good
> plan would have remained in cache.
> But, OK, the reverse can happen: the old plan was bad, but statistics
> have been updated recently, so now you get a good plan.
> As for your problem the other day, you did not include any error message,
> but I would guess that it was a temporary network problem, and it would
> have gone away even if you had not restarted SQL Server.
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
Thanks, Erland. Once again, your response is thorough and informative.
|||"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.com> wrote in message
news:13lguvsc3jaql29@.corp.supernews.com...[vbcol=seagreen]
> "Neil" <nospam@.nospam.net> wrote in message
> news:NQZ5j.69213$RX.4340@.newssvr11.news.prodigy.ne t...
> Yes. I disagree.
> I've run systems with uptimes measured in years.
> I see no value in rebooting a correctly setup system.
>
Thanks.

Once a week or once a month

My POV is that: a) doing it once a week might prevent situations such as the
one yesterday; b) even without situations like the one yesterday,
performance may be degrading over the course of the month, without our being
aware of it, and rebooting once a week might help performance.

Any thoughts on this?

Thanks!

NeilJust because the reboot fixed the issue doesn't mean that a preventative
reboot will stop it from occuring.

A reboot might not have been needed to resolve the issue in the first place.
Possibly a configuration change
or bouncing a service could have resolved it. My advice is to spend some
time researching the issue and if
you cant find a way to resolve it then find a way to detect it and have it
perform the least intrusive form of corrective action.

-Mike

"Neil" <nospam@.nospam.netwrote in message
news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy. net...

Quote:

Originally Posted by

|||Why does he reboot at all?

--
Tom

----------------
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau
"Neil" <nospam@.nospam.netwrote in message
news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy. net...
Running a SQL 7 system on a Windows 2000 server using Access 2000 on client
machines as a front end. System administrator currently reboots the server
once a month. Yesterday we had some weird thing with the database where
users were getting ODBC errors when trying to access it. Rebooted the
server, everything was fine. Suggested to the sa that he reboot the server
once a week. He said he already does it once a month, and that's sufficient.

Any thoughts on this?

Thanks!

Neil|||OK, that's fine. But my POV is that rebooting in general, and resetting the
system memory, is a good thing to do. I take it that you disagree?

"Michael Abair" <mabair@.autotask.comwrote in message
news:eTxBHcEOIHA.2064@.TK2MSFTNGP06.phx.gbl...

Quote:

Originally Posted by

Just because the reboot fixed the issue doesn't mean that a preventative
reboot will stop it from occuring.
>
A reboot might not have been needed to resolve the issue in the first
place. Possibly a configuration change
or bouncing a service could have resolved it. My advice is to spend some
time researching the issue and if
you cant find a way to resolve it then find a way to detect it and have it
perform the least intrusive form of corrective action.
>
-Mike
>
"Neil" <nospam@.nospam.netwrote in message
news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy. net...

Quote:

Originally Posted by

>Running a SQL 7 system on a Windows 2000 server using Access 2000 on
>client machines as a front end. System administrator currently reboots
>the server once a month. Yesterday we had some weird thing with the
>database where users were getting ODBC errors when trying to access it.
>Rebooted the server, everything was fine. Suggested to the sa that he
>reboot the server once a week. He said he already does it once a month,
>and that's sufficient.
>>
>My POV is that: a) doing it once a week might prevent situations such as
>the one yesterday; b) even without situations like the one yesterday,
>performance may be degrading over the course of the month, without our
>being aware of it, and rebooting once a week might help performance.
>>
>Any thoughts on this?
>>
>Thanks!
>>
>Neil
>>

>
>

|||See my response to Michael in this thread.

"Tom Moreau" <tom@.dont.spam.me.cips.cawrote in message
news:%23LFLkcEOIHA.4196@.TK2MSFTNGP04.phx.gbl...

Quote:

Originally Posted by

Why does he reboot at all?
>
--
Tom
>
----------------
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau
>
>
"Neil" <nospam@.nospam.netwrote in message
news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy. net...
Running a SQL 7 system on a Windows 2000 server using Access 2000 on
client
machines as a front end. System administrator currently reboots the server
once a month. Yesterday we had some weird thing with the database where
users were getting ODBC errors when trying to access it. Rebooted the
server, everything was fine. Suggested to the sa that he reboot the server
once a week. He said he already does it once a month, and that's
sufficient.
>
My POV is that: a) doing it once a week might prevent situations such as
the
one yesterday; b) even without situations like the one yesterday,
performance may be degrading over the course of the month, without our
being
aware of it, and rebooting once a week might help performance.
>
Any thoughts on this?
>
Thanks!
>
Neil
>
>

|||Neil (nospam@.nospam.net) writes:

Quote:

Originally Posted by

OK, that's fine. But my POV is that rebooting in general, and resetting
the system memory, is a good thing to do. I take it that you disagree?

I do. Unless there is some known issues, there is rarely any reason to
reboot SQL Server regularly. OK, so you have SQL 7, and this version is a
bit old. Nevertheless, it has the same basic architecture as subsequent
SQL Server versions. The predecessors 6.x were less stable. (In 6.0 there
was a bug that compelled you to restart the bug about every 48th day.
There was some counter somewhere that wrapped around after 49 days.)

As for rebooting helping performance, it may be the other way round.
When you reboot, the entire plan cache will be thrown away, and until
the plan has built up, the server will spend more time compiling. But
that's the only thing. Say that you have a table with date column,
into which the current date is typically inserted, and queries against
this table are typically for the recent days. If the query is a stored
procedure or is parameterised, the plan will be built using that date.
But if statistics are out of date, the estimates will be wrong, and you
may get a bad plan. Had you never restarted the server, the old good
plan would have remained in cache.

But, OK, the reverse can happen: the old plan was bad, but statistics
have been updated recently, so now you get a good plan.

As for your problem the other day, you did not include any error message,
but I would guess that it was a temporary network problem, and it would
have gone away even if you had not restarted SQL Server.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Why does the system memory need to be reset? I've seen SQL Servers stay up
for months and not need a reboot. That's what High Availability is all
about.

--
Tom

"Michael Abair" <mabair@.autotask.comwrote in message
news:eTxBHcEOIHA.2064@.TK2MSFTNGP06.phx.gbl...

Quote:

Originally Posted by

Quote:

Originally Posted by

>
>

|||"Neil" <nospam@.nospam.netwrote in message
news:NQZ5j.69213$RX.4340@.newssvr11.news.prodigy.ne t...

Quote:

Originally Posted by

OK, that's fine. But my POV is that rebooting in general, and resetting
the system memory, is a good thing to do. I take it that you disagree?
>

Yes. I disagree.

I've run systems with uptimes measured in years.

I see no value in rebooting a correctly setup system.

Quote:

Originally Posted by

"Michael Abair" <mabair@.autotask.comwrote in message
news:eTxBHcEOIHA.2064@.TK2MSFTNGP06.phx.gbl...

Quote:

Originally Posted by

>Just because the reboot fixed the issue doesn't mean that a preventative
>reboot will stop it from occuring.
>>
>A reboot might not have been needed to resolve the issue in the first
>place. Possibly a configuration change
>or bouncing a service could have resolved it. My advice is to spend some
>time researching the issue and if
>you cant find a way to resolve it then find a way to detect it and have
>it perform the least intrusive form of corrective action.
>>
>-Mike
>>
>"Neil" <nospam@.nospam.netwrote in message
>news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy. net...

Quote:

Originally Posted by

>>Running a SQL 7 system on a Windows 2000 server using Access 2000 on
>>client machines as a front end. System administrator currently reboots
>>the server once a month. Yesterday we had some weird thing with the
>>database where users were getting ODBC errors when trying to access it.
>>Rebooted the server, everything was fine. Suggested to the sa that he
>>reboot the server once a week. He said he already does it once a month,
>>and that's sufficient.
>>>
>>My POV is that: a) doing it once a week might prevent situations such as
>>the one yesterday; b) even without situations like the one yesterday,
>>performance may be degrading over the course of the month, without our
>>being aware of it, and rebooting once a week might help performance.
>>>
>>Any thoughts on this?
>>>
>>Thanks!
>>>
>>Neil
>>>

>>
>>

>
>

|||"Erland Sommarskog" <esquel@.sommarskog.sewrote in message
news:Xns99FEEDF6C864Yazorman@.127.0.0.1...

Quote:

Originally Posted by

Neil (nospam@.nospam.net) writes:

Quote:

Originally Posted by

>OK, that's fine. But my POV is that rebooting in general, and resetting
>the system memory, is a good thing to do. I take it that you disagree?

>
I do. Unless there is some known issues, there is rarely any reason to
reboot SQL Server regularly. OK, so you have SQL 7, and this version is a
bit old. Nevertheless, it has the same basic architecture as subsequent
SQL Server versions. The predecessors 6.x were less stable. (In 6.0 there
was a bug that compelled you to restart the bug about every 48th day.
There was some counter somewhere that wrapped around after 49 days.)
>
As for rebooting helping performance, it may be the other way round.
When you reboot, the entire plan cache will be thrown away, and until
the plan has built up, the server will spend more time compiling. But
that's the only thing. Say that you have a table with date column,
into which the current date is typically inserted, and queries against
this table are typically for the recent days. If the query is a stored
procedure or is parameterised, the plan will be built using that date.
But if statistics are out of date, the estimates will be wrong, and you
may get a bad plan. Had you never restarted the server, the old good
plan would have remained in cache.
>
But, OK, the reverse can happen: the old plan was bad, but statistics
have been updated recently, so now you get a good plan.
>
As for your problem the other day, you did not include any error message,
but I would guess that it was a temporary network problem, and it would
have gone away even if you had not restarted SQL Server.
>
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
>
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx

Thanks, Erland. Once again, your response is thorough and informative.|||"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.comwrote in message
news:13lguvsc3jaql29@.corp.supernews.com...

Quote:

Originally Posted by

"Neil" <nospam@.nospam.netwrote in message
news:NQZ5j.69213$RX.4340@.newssvr11.news.prodigy.ne t...

Quote:

Originally Posted by

>OK, that's fine. But my POV is that rebooting in general, and resetting
>the system memory, is a good thing to do. I take it that you disagree?
>>

>
Yes. I disagree.
>
I've run systems with uptimes measured in years.
>
I see no value in rebooting a correctly setup system.
>
>

Quote:

Originally Posted by

>"Michael Abair" <mabair@.autotask.comwrote in message
>news:eTxBHcEOIHA.2064@.TK2MSFTNGP06.phx.gbl...

Quote:

Originally Posted by

>>Just because the reboot fixed the issue doesn't mean that a preventative
>>reboot will stop it from occuring.
>>>
>>A reboot might not have been needed to resolve the issue in the first
>>place. Possibly a configuration change
>>or bouncing a service could have resolved it. My advice is to spend
>>some time researching the issue and if
>>you cant find a way to resolve it then find a way to detect it and have
>>it perform the least intrusive form of corrective action.
>>>
>>-Mike
>>>
>>"Neil" <nospam@.nospam.netwrote in message
>>news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy. net...
>>>Running a SQL 7 system on a Windows 2000 server using Access 2000 on
>>>client machines as a front end. System administrator currently reboots
>>>the server once a month. Yesterday we had some weird thing with the
>>>database where users were getting ODBC errors when trying to access it.
>>>Rebooted the server, everything was fine. Suggested to the sa that he
>>>reboot the server once a week. He said he already does it once a month,
>>>and that's sufficient.
>>
>>>My POV is that: a) doing it once a week might prevent situations such
>>>as the one yesterday; b) even without situations like the one
>>>yesterday, performance may be degrading over the course of the month,
>>>without our being aware of it, and rebooting once a week might help
>>>performance.
>>
>>>Any thoughts on this?
>>
>>>Thanks!
>>
>>>Neil
>>
>>>
>>>

Thanks.|||

Quote:

Originally Posted by

"Neil" <nospam@.nospam.netwrote in message
news:NQZ5j.69213$RX.4340@.newssvr11.news.prodigy.ne t...
OK, that's fine. But my POV is that rebooting in general, and resetting
the
system memory, is a good thing to do. I take it that you disagree?
>
"Michael Abair" <mabair@.autotask.comwrote in message
news:eTxBHcEOIHA.2064@.TK2MSFTNGP06.phx.gbl...

Quote:

Originally Posted by

>Just because the reboot fixed the issue doesn't mean that a preventative
>reboot will stop it from occuring.
>>
>A reboot might not have been needed to resolve the issue in the first
>place. Possibly a configuration change
>or bouncing a service could have resolved it. My advice is to spend some
>time researching the issue and if
>you cant find a way to resolve it then find a way to detect it and have
>it
>perform the least intrusive form of corrective action.
>>
>-Mike
>>
>"Neil" <nospam@.nospam.netwrote in message
>news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy. net...

Quote:

Originally Posted by

"Tom Moreau" <tom@.dont.spam.me.cips.cawrote in message
news:uuaNHcFOIHA.4948@.TK2MSFTNGP02.phx.gbl...

Quote:

Originally Posted by

Why does the system memory need to be reset? I've seen SQL Servers stay
up
for months and not need a reboot. That's what High Availability is all
about.
>
--
Tom
>
----------------
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau
>
>

Just as a general practice with Windows apps, that memory gets lost or
corrupted over time. Perhaps not with SQL Server. But there are other apps
running on it. PC Anywhere is installed as a host on that machine. I don't
know how much memory degradation, if any, occurs from that app. Occasionally
the machine is used to test the front end app (though it's not the primary
machine for that purpose).|||If memory is truly getting lost or corrupted, then I'd troubleshoot the
specific problem.

--
Tom

Quote:

Originally Posted by

Quote:

Originally Posted by

>Just because the reboot fixed the issue doesn't mean that a preventative
>reboot will stop it from occuring.
>>
>A reboot might not have been needed to resolve the issue in the first
>place. Possibly a configuration change
>or bouncing a service could have resolved it. My advice is to spend some
>time researching the issue and if
>you cant find a way to resolve it then find a way to detect it and have
>it
>perform the least intrusive form of corrective action.
>>
>-Mike
>>
>"Neil" <nospam@.nospam.netwrote in message
>news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy. net...

Quote:

Originally Posted by

"Tom Moreau" <tom@.dont.spam.me.cips.cawrote in message
news:uuaNHcFOIHA.4948@.TK2MSFTNGP02.phx.gbl...

Quote:

Originally Posted by

Just as a general practice with Windows apps, that memory gets lost or
corrupted over time. Perhaps not with SQL Server. But there are other apps
running on it. PC Anywhere is installed as a host on that machine. I don't
know how much memory degradation, if any, occurs from that app. Occasionally
the machine is used to test the front end app (though it's not the primary
machine for that purpose).|||"Neil" <nospam@.nospam.netwrote in message
news:s2f6j.23284$4V6.14684@.newssvr14.news.prodigy. net...

Quote:

Originally Posted by

>
>
>
Just as a general practice with Windows apps, that memory gets lost or
corrupted over time. Perhaps not with SQL Server. But there are other apps
running on it. PC Anywhere is installed as a host on that machine.

Unless there's a specific need for PCAnywhere, I'd get rid of it and
administer the machine via remote desktop.

Works much better.

Quote:

Originally Posted by

I don't know how much memory degradation, if any, occurs from that app.
Occasionally the machine is used to test the front end app (though it's
not the primary machine for that purpose).

Well in that csae you've got other issues with the machine.

Which if it's a purely dev machine or one where shutdowns don't impact the
business, you may be ok.

The prod environments I work in tend to be 24/7 so shutdowns are very
infrequent.

Also if you're doing a soft-reboot, that's a bit "nicer" to the hardware
than a hard-reboot which can shorten the lifespan of components.

Quote:

Originally Posted by

>
>

--
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.comwrote in message
news:13lj8p2grq8eab@.corp.supernews.com...

Quote:

Originally Posted by

"Neil" <nospam@.nospam.netwrote in message
news:s2f6j.23284$4V6.14684@.newssvr14.news.prodigy. net...

Quote:

Originally Posted by

>>
>>
>>
>Just as a general practice with Windows apps, that memory gets lost or
>corrupted over time. Perhaps not with SQL Server. But there are other
>apps running on it. PC Anywhere is installed as a host on that machine.

>
Unless there's a specific need for PCAnywhere, I'd get rid of it and
administer the machine via remote desktop.
>
Works much better.
>
>

Quote:

Originally Posted by

>I don't know how much memory degradation, if any, occurs from that app.
>Occasionally the machine is used to test the front end app (though it's
>not the primary machine for that purpose).

>
Well in that csae you've got other issues with the machine.
>
Which if it's a purely dev machine or one where shutdowns don't impact the
business, you may be ok.
>
The prod environments I work in tend to be 24/7 so shutdowns are very
infrequent.
>
Also if you're doing a soft-reboot, that's a bit "nicer" to the hardware
than a hard-reboot which can shorten the lifespan of components.
>
>

Quote:

Originally Posted by

>>
>>

>
>
>
--
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com
http://www.greenms.com/sqlserver.html
>
>

One problem with remote desktop is that you can't transfer files or transfer
the clipboard contents (or can you?). I use those two functions all the
time.|||Neil wrote:

Quote:

Originally Posted by

One problem with remote desktop is that you can't transfer files or transfer
the clipboard contents (or can you?). I use those two functions all the
time.

The clipboard contents are auto-copied whenever they change on either
side. I don't think you can transfer files, but you can work around
that with an FTP server.|||Neil (nospam@.nospam.net) writes:

Quote:

Originally Posted by

One problem with remote desktop is that you can't transfer files or
transfer the clipboard contents (or can you?). I use those two functions
all the time.

You can. You can configure this under Local Resources. I think clipboard
is shared by default, so if you put something on the clipboard on the
remote machine, it makes it to the local machine automatically.

The way to transfer files, is a little funny, though. You make the local
drives available to the remote machine, so that they appear as shared
there. Since this is a security issue, it's not recommendable to always
expose your disks.

We don't use PC Anywhere in our shop, but we use PC Duo which is a
similar product. About all customers has PC Duo clients on their
servers, and that's how we connect to them. The major advantage is
that with Remote Desktop, is that if someone else connect, you may lose
your session. With PC-Duo you can see that someone else is there.
And moving files is easier with PC-Duo than Remote Desktop.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||"Erland Sommarskog" <esquel@.sommarskog.sewrote in message
news:Xns99FFEF5871026Yazorman@.127.0.0.1...

Quote:

Originally Posted by

Neil (nospam@.nospam.net) writes:

Quote:

Originally Posted by

>One problem with remote desktop is that you can't transfer files or
>transfer the clipboard contents (or can you?). I use those two functions
>all the time.

>
You can. You can configure this under Local Resources. I think clipboard
is shared by default, so if you put something on the clipboard on the
remote machine, it makes it to the local machine automatically.
>
The way to transfer files, is a little funny, though. You make the local
drives available to the remote machine, so that they appear as shared
there. Since this is a security issue, it's not recommendable to always
expose your disks.
>
We don't use PC Anywhere in our shop, but we use PC Duo which is a
similar product. About all customers has PC Duo clients on their
servers, and that's how we connect to them. The major advantage is
that with Remote Desktop, is that if someone else connect, you may lose
your session. With PC-Duo you can see that someone else is there.
And moving files is easier with PC-Duo than Remote Desktop.
>
>

So you'd recommend PC Duo over Remote Desktop? Is the performance as good?|||"Neil" <nospam@.nospam.netwrote in message
news:q5i6j.4985$fl7.132@.newssvr22.news.prodigy.net ...

Quote:

Originally Posted by

Quote:

Originally Posted by

>
>
One problem with remote desktop is that you can't transfer files or
transfer the clipboard contents (or can you?). I use those two functions
all the time.

You can transfer the clipboard settings in Win2K.

(Though I think you need Server 2003 for the file transfer function (it maps
the drives from your client to the server. I use that a lot.)

Quote:

Originally Posted by

>
>
>

--
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||Neil (nospam@.nospam.net) writes:

Quote:

Originally Posted by

So you'd recommend PC Duo over Remote Desktop? Is the performance as good?

It depends on the purpose. When I want to connect to machine at work,
I definitely prefer Remote Desktop over PC-Duo. At least in the past I
have had issue with PC-Duo redrawing the screen like crazy, or it has
stopped redrawing. A crazy one I remember was that if I connect to my
machine with PC-Duo, and I had Query Analyzer up with a query grid, it
would halt somewhere. I was able to get it to resume if I minimiezed QA.
Now, since PC-Duo had not drawn the entire screen, I had to find the
minimize button as if I was blind-folded. Even more fun, if other windows
were on top of QA. But I should stress that this was quite a few years
and versions of PC-Duo ago.

So for performance and access to a workstation I prefer Remote Desktop.

But if several people need to access the same server console, I think
PC Duo is better. It's also better if you need to move files in any
direction.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.comwrote in message
news:13lla9gfb13pp76@.corp.supernews.com...

Quote:

Originally Posted by

>
"Neil" <nospam@.nospam.netwrote in message
news:q5i6j.4985$fl7.132@.newssvr22.news.prodigy.net ...

Quote:

Originally Posted by

Quote:

Originally Posted by

>>>

>>
>>
>One problem with remote desktop is that you can't transfer files or
>transfer the clipboard contents (or can you?). I use those two functions
>all the time.

>
You can transfer the clipboard settings in Win2K.
>

"Can" transfer, or they're transferred automatically?|||"Neil" <nospam@.nospam.netwrote in message
news:RPP6j.5129$fl7.785@.newssvr22.news.prodigy.net ...

Quote:

Originally Posted by

>
"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.comwrote in
message news:13lla9gfb13pp76@.corp.supernews.com...

Quote:

Originally Posted by

>>
>"Neil" <nospam@.nospam.netwrote in message
>news:q5i6j.4985$fl7.132@.newssvr22.news.prodigy.net ...

Quote:

Originally Posted by

>>>
>>
>>>
>>>
>>One problem with remote desktop is that you can't transfer files or
>>transfer the clipboard contents (or can you?). I use those two functions
>>all the time.

>>
>You can transfer the clipboard settings in Win2K.
>>

>
"Can" transfer, or they're transferred automatically?
>

Transferred automatically.

Quote:

Originally Posted by

>
>

--
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||On Dec 6, 2:05 pm, "Neil" <nos...@.nospam.netwrote:

Quote:

Originally Posted by

Neil, along with the great suggestions I would explore upgrading your
box and software. Even look at client configurations, how do they
login, are they booting up daily or are the client machines left on
over night or several days thus causing the problem in itself. Does
your SA have that power to dictate what is sufficient? What does it
harm? Granted rebooting and shutting down a server box is not good for
the long term.

HTH...|||OK, here's another one: no way to sent Ctrl+Alt+Del. With PCAnywhere, I can
send a Ctrl+Alt+Del and bring up Task Manager. How would one do that in
remote desktop?

"Ed Murphy" <emurphy42@.socal.rr.comwrote in message
news:4759bb35$0$2384$4c368faf@.roadrunner.com...

Quote:

Originally Posted by

Neil wrote:
>

Quote:

Originally Posted by

>One problem with remote desktop is that you can't transfer files or
>transfer the clipboard contents (or can you?). I use those two functions
>all the time.

>
The clipboard contents are auto-copied whenever they change on either
side. I don't think you can transfer files, but you can work around
that with an FTP server.

|||"Neil" <nospam@.nospam.netwrote in message
news:PyCaj.568$se5.316@.nlpi069.nbdc.sbc.com...

Quote:

Originally Posted by

OK, here's another one: no way to sent Ctrl+Alt+Del. With PCAnywhere, I
can send a Ctrl+Alt+Del and bring up Task Manager. How would one do that
in remote desktop?

http://support.microsoft.com/kb/186624
CTRL-ALT-END

Quote:

Originally Posted by

>
>
>
"Ed Murphy" <emurphy42@.socal.rr.comwrote in message
news:4759bb35$0$2384$4c368faf@.roadrunner.com...

Quote:

Originally Posted by

>Neil wrote:
>>

Quote:

Originally Posted by

>>One problem with remote desktop is that you can't transfer files or
>>transfer the clipboard contents (or can you?). I use those two functions
>>all the time.

>>
>The clipboard contents are auto-copied whenever they change on either
>side. I don't think you can transfer files, but you can work around
>that with an FTP server.

>
>

--
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||Hey, thanks, that's great.

I was also wondering about toggling between full screen and windowed mode
(Alt+Enter in PCAnywhere). I see that's CTRL+ALT+BREAK in TS. But, while
I'm glad that TS has a shortcut for that, that's a bit unwieldy, especially
since Break on my laptop is Fn+Break!! Guess I'll just have to use the mouse
to toggle.

Neil

"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.comwrote in message
news:13mm5akkg0q5l4b@.corp.supernews.com...

Quote:

Originally Posted by

"Neil" <nospam@.nospam.netwrote in message
news:PyCaj.568$se5.316@.nlpi069.nbdc.sbc.com...

Quote:

Originally Posted by

>OK, here's another one: no way to sent Ctrl+Alt+Del. With PCAnywhere, I
>can send a Ctrl+Alt+Del and bring up Task Manager. How would one do that
>in remote desktop?

>
http://support.microsoft.com/kb/186624
>
CTRL-ALT-END
>
>

Quote:

Originally Posted by

>>
>>
>>
>"Ed Murphy" <emurphy42@.socal.rr.comwrote in message
>news:4759bb35$0$2384$4c368faf@.roadrunner.com...

Quote:

Originally Posted by

>>Neil wrote:
>>>
>>>One problem with remote desktop is that you can't transfer files or
>>>transfer the clipboard contents (or can you?). I use those two
>>>functions all the time.
>>>
>>The clipboard contents are auto-copied whenever they change on either
>>side. I don't think you can transfer files, but you can work around
>>that with an FTP server.

>>
>>

>
>
>
--
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com
http://www.greenms.com/sqlserver.html
>
>

|||"Neil" <nospam@.nospam.netwrote in message
news:YXHaj.33923$Pv2.8297@.newssvr23.news.prodigy.n et...

Quote:

Originally Posted by

Hey, thanks, that's great.
>
I was also wondering about toggling between full screen and windowed mode
(Alt+Enter in PCAnywhere). I see that's CTRL+ALT+BREAK in TS. But, while
I'm glad that TS has a shortcut for that, that's a bit unwieldy,
especially since Break on my laptop is Fn+Break!! Guess I'll just have to
use the mouse to toggle.
>

Yeah there were a few there that I didn't even know about.

Very useful.

Quote:

Originally Posted by

Neil

Quote:

Originally Posted by

>>
>>
>--
>Greg Moore
>SQL Server DBA Consulting Remote and Onsite available!
>Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html
>>
>>

>
>

Quote:

Originally Posted by

"Neil" <nospam@.nospam.netwrote in message
news:YXHaj.33923$Pv2.8297@.newssvr23.news.prodigy.n et...

Quote:

Originally Posted by

>Hey, thanks, that's great.
>>
>I was also wondering about toggling between full screen and windowed mode
>(Alt+Enter in PCAnywhere). I see that's CTRL+ALT+BREAK in TS. But, while
>I'm glad that TS has a shortcut for that, that's a bit unwieldy,
>especially since Break on my laptop is Fn+Break!! Guess I'll just have to
>use the mouse to toggle.
>>

>
Yeah there were a few there that I didn't even know about.
>
Very useful.
>

You'd think (just a thought) that MS would give use a dropdown with some of
the functions. Or maybe just a list of shortcuts so we could have them
handy. I guess that's too much to ask for...:-(|||"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.comwrote in message
news:13mnm3t85tebm62@.corp.supernews.com...

Quote:

Originally Posted by

"Neil" <nospam@.nospam.netwrote in message
news:YXHaj.33923$Pv2.8297@.newssvr23.news.prodigy.n et...

Quote:

Originally Posted by

>
Yeah there were a few there that I didn't even know about.
>
Very useful.
>
>

Hey, you know, I just found out that there's an option when you connect
through RDC to apply Windows key combinations to the remote computer!
Doesn't seem to work for Ctrl-Alt-Del. But seems to work for Alt-Tab.
Haven't tried it with others yet. But that's a great thing.

Once a week or once a month

Running a SQL 7 system on a Windows 2000 server using Access 2000 on client
machines as a front end. System administrator currently reboots the server
once a month. Yesterday we had some weird thing with the database where
users were getting ODBC errors when trying to access it. Rebooted the
server, everything was fine. Suggested to the sa that he reboot the server
once a week. He said he already does it once a month, and that's sufficient.
My POV is that: a) doing it once a week might prevent situations such as the
one yesterday; b) even without situations like the one yesterday,
performance may be degrading over the course of the month, without our being
aware of it, and rebooting once a week might help performance.
Any thoughts on this?
Thanks!
NeilJust because the reboot fixed the issue doesn't mean that a preventative
reboot will stop it from occuring.
A reboot might not have been needed to resolve the issue in the first place.
Possibly a configuration change
or bouncing a service could have resolved it. My advice is to spend some
time researching the issue and if
you cant find a way to resolve it then find a way to detect it and have it
perform the least intrusive form of corrective action.
-Mike
"Neil" <nospam@.nospam.net> wrote in message
news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy.net...
> Running a SQL 7 system on a Windows 2000 server using Access 2000 on
> client machines as a front end. System administrator currently reboots the
> server once a month. Yesterday we had some weird thing with the database
> where users were getting ODBC errors when trying to access it. Rebooted
> the server, everything was fine. Suggested to the sa that he reboot the
> server once a week. He said he already does it once a month, and that's
> sufficient.
> My POV is that: a) doing it once a week might prevent situations such as
> the one yesterday; b) even without situations like the one yesterday,
> performance may be degrading over the course of the month, without our
> being aware of it, and rebooting once a week might help performance.
> Any thoughts on this?
> Thanks!
> Neil
>|||Why does he reboot at all?
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau
"Neil" <nospam@.nospam.net> wrote in message
news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy.net...
Running a SQL 7 system on a Windows 2000 server using Access 2000 on client
machines as a front end. System administrator currently reboots the server
once a month. Yesterday we had some weird thing with the database where
users were getting ODBC errors when trying to access it. Rebooted the
server, everything was fine. Suggested to the sa that he reboot the server
once a week. He said he already does it once a month, and that's sufficient.
My POV is that: a) doing it once a week might prevent situations such as the
one yesterday; b) even without situations like the one yesterday,
performance may be degrading over the course of the month, without our being
aware of it, and rebooting once a week might help performance.
Any thoughts on this?
Thanks!
Neil|||OK, that's fine. But my POV is that rebooting in general, and resetting the
system memory, is a good thing to do. I take it that you disagree?
"Michael Abair" <mabair@.autotask.com> wrote in message
news:eTxBHcEOIHA.2064@.TK2MSFTNGP06.phx.gbl...
> Just because the reboot fixed the issue doesn't mean that a preventative
> reboot will stop it from occuring.
> A reboot might not have been needed to resolve the issue in the first
> place. Possibly a configuration change
> or bouncing a service could have resolved it. My advice is to spend some
> time researching the issue and if
> you cant find a way to resolve it then find a way to detect it and have it
> perform the least intrusive form of corrective action.
> -Mike
> "Neil" <nospam@.nospam.net> wrote in message
> news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy.net...
>|||See my response to Michael in this thread.
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:%23LFLkcEOIHA.4196@.TK2MSFTNGP04.phx.gbl...
> Why does he reboot at all?
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
> SQL Server MVP
> Toronto, ON Canada
> https://mvp.support.microsoft.com/profile/Tom.Moreau
>
> "Neil" <nospam@.nospam.net> wrote in message
> news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy.net...
> Running a SQL 7 system on a Windows 2000 server using Access 2000 on
> client
> machines as a front end. System administrator currently reboots the server
> once a month. Yesterday we had some weird thing with the database where
> users were getting ODBC errors when trying to access it. Rebooted the
> server, everything was fine. Suggested to the sa that he reboot the server
> once a week. He said he already does it once a month, and that's
> sufficient.
> My POV is that: a) doing it once a week might prevent situations such as
> the
> one yesterday; b) even without situations like the one yesterday,
> performance may be degrading over the course of the month, without our
> being
> aware of it, and rebooting once a week might help performance.
> Any thoughts on this?
> Thanks!
> Neil
>|||Neil (nospam@.nospam.net) writes:
> OK, that's fine. But my POV is that rebooting in general, and resetting
> the system memory, is a good thing to do. I take it that you disagree?
I do. Unless there is some known issues, there is rarely any reason to
reboot SQL Server regularly. OK, so you have SQL 7, and this version is a
bit old. Nevertheless, it has the same basic architecture as subsequent
SQL Server versions. The predecessors 6.x were less stable. (In 6.0 there
was a bug that compelled you to restart the bug about every 48th day.
There was some counter somewhere that wrapped around after 49 days.)
As for rebooting helping performance, it may be the other way round.
When you reboot, the entire plan cache will be thrown away, and until
the plan has built up, the server will spend more time compiling. But
that's the only thing. Say that you have a table with date column,
into which the current date is typically inserted, and queries against
this table are typically for the recent days. If the query is a stored
procedure or is parameterised, the plan will be built using that date.
But if statistics are out of date, the estimates will be wrong, and you
may get a bad plan. Had you never restarted the server, the old good
plan would have remained in cache.
But, OK, the reverse can happen: the old plan was bad, but statistics
have been updated recently, so now you get a good plan.
As for your problem the other day, you did not include any error message,
but I would guess that it was a temporary network problem, and it would
have gone away even if you had not restarted SQL Server.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Why does the system memory need to be reset? I've seen SQL Servers stay up
for months and not need a reboot. That's what High Availability is all
about.
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau
"Neil" <nospam@.nospam.net> wrote in message
news:NQZ5j.69213$RX.4340@.newssvr11.news.prodigy.net...
OK, that's fine. But my POV is that rebooting in general, and resetting the
system memory, is a good thing to do. I take it that you disagree?
"Michael Abair" <mabair@.autotask.com> wrote in message
news:eTxBHcEOIHA.2064@.TK2MSFTNGP06.phx.gbl...
> Just because the reboot fixed the issue doesn't mean that a preventative
> reboot will stop it from occuring.
> A reboot might not have been needed to resolve the issue in the first
> place. Possibly a configuration change
> or bouncing a service could have resolved it. My advice is to spend some
> time researching the issue and if
> you cant find a way to resolve it then find a way to detect it and have it
> perform the least intrusive form of corrective action.
> -Mike
> "Neil" <nospam@.nospam.net> wrote in message
> news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy.net...
>|||"Neil" <nospam@.nospam.net> wrote in message
news:NQZ5j.69213$RX.4340@.newssvr11.news.prodigy.net...
> OK, that's fine. But my POV is that rebooting in general, and resetting
> the system memory, is a good thing to do. I take it that you disagree?
>
Yes. I disagree.
I've run systems with uptimes measured in years.
I see no value in rebooting a correctly setup system.

> "Michael Abair" <mabair@.autotask.com> wrote in message
> news:eTxBHcEOIHA.2064@.TK2MSFTNGP06.phx.gbl...
>|||"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.com> wrote in message
news:13lguvsc3jaql29@.corp.supernews.com...[vbcol=seagreen]
> "Neil" <nospam@.nospam.net> wrote in message
> news:NQZ5j.69213$RX.4340@.newssvr11.news.prodigy.net...
> Yes. I disagree.
> I've run systems with uptimes measured in years.
> I see no value in rebooting a correctly setup system.
>
Thanks.|||
> "Neil" <nospam@.nospam.net> wrote in message
> news:NQZ5j.69213$RX.4340@.newssvr11.news.prodigy.net...
> OK, that's fine. But my POV is that rebooting in general, and resetting
> the
> system memory, is a good thing to do. I take it that you disagree?
> "Michael Abair" <mabair@.autotask.com> wrote in message
> news:eTxBHcEOIHA.2064@.TK2MSFTNGP06.phx.gbl...
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:uuaNHcFOIHA.4948@.TK2MSFTNGP02.phx.gbl...[vbcol=seagreen]
> Why does the system memory need to be reset? I've seen SQL Servers stay
> up
> for months and not need a reboot. That's what High Availability is all
> about.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
> SQL Server MVP
> Toronto, ON Canada
> https://mvp.support.microsoft.com/profile/Tom.Moreau
>
Just as a general practice with Windows apps, that memory gets lost or
corrupted over time. Perhaps not with SQL Server. But there are other apps
running on it. PC Anywhere is installed as a host on that machine. I don't
know how much memory degradation, if any, occurs from that app. Occasionally
the machine is used to test the front end app (though it's not the primary
machine for that purpose).

Friday, March 23, 2012

OlyMars help?

Hi guys,
It seems that my last question was a little involved :)

Has any one got experience of working with OlyMars on Windows XP?

If so did you have problems with the OlyMars Tutorial in particular running the batch scripts?

I'm stuck on the section of Generation of Ready to Use Objects

Any help is appreciated :)

FBI think your best bet on this is one of the resources on this page:OlyMars: SQL Server Centric .NET Code Generator.

In particular there is a newsgroup that should help you: news://msnews.microsoft.com/microsoft.public.fr.dotnet.olymars. I see questions posted there in both French and English.

Terri|||..Good Stuff! Thanks Terri, I'll check it out now :)

Wednesday, March 21, 2012

Oleddb dropdown list is empty in Excel

Hello,

I have an issue with connecting Excel to an analysis Services 2005 database. The computer is running Windows XP Sp2 and Office XP. I installed the oledb driver 9.0 but when I tried to connect with the pivot table and I want to create the connection, the dropdown list of the data provider is empty. I tried on another computer with Excel XP and the system is working fine.
Is there somebody that could help?

Thank you

It sounds like it might be a connection/networking issue? On the computer, try making an ODBC Data Source. You can do this by choosing Start->Control Panel->Administrative Tools->Data Sources (ODBC).

From here, on the User DSN tab, press the Add... button. On the list of providers, you should see "SQL Native Client" or "SQL Server". Choose one of these. On the next dialog, you should see 3 fields, Name, Description, and Server. Use the drop down list of "Server" to see if you can find the server that you're looking for. If you can, then it's something else. If you can't, then talk to your system administrator about troubleshooting why that server can't be seen from your computer. Either way, you can cancel and close these dialogs without making any changes to your computer. This should only test the visibility of the server to your computer.

Hope this helps. Please follow up if this doesn't help you.

|||

Thanks for the help but it doesn't work. If I try to create an ODBC connection the system is working fine. It seems to me that the problem is related only to the OleDb component for Analysis Services. I am going to try to uninstall and install back office to see it this will fix something.

Thanks again!

OLEDB question

This may be a newbie question but here it goes. I have SQL Server 2000 running on a windows server 2003 machine. When i have my database local, on MSDE everything is fine. But when i switch my code to move to the server, (after i've attached the database within the server) it tells me that server either does not exist or login failed. Now here is my connection statement

OleDbConnection m_conn;

string connectionString = "Provider=SQLOLEDB;Data Source=SERVER1;Initial Catalog=workups;Integrated Security=SSPI";

m_conn = new OleDbConnection(connectionString);

Now like i said when i change the Data Source from (local) to SERVER1 it gives me this error, however on the server all the data is fine, and i can view it locally on the server. Anyone know what's wrong or if it's a coding issue?

Thanks

Dan

What's the error message?|||

Error message in my event log, i log the actual exception here it is

System.Data.OleDb.OleDbException: [DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.

at System.Data.OleDb.OleDbConnection.ProcessResults(Int32 hr)

at System.Data.OleDb.OleDbConnection.InitializeProvider()

at System.Data.OleDb.OleDbConnection.Open()

at DotThisSoftware.SqlClient.DatabaseFactory.Open() in C:\Documents and Settings\drux\My Documents\Visual Studio Projects\DotThisSoftware.SqlClient\DatabaseFactory.cs:line 88

THanks

Dan

|||I see, have you verified, since you're using Integrated Security, that the current user running the application can logon to the remote server?|||

Ok, i can't log into the server through visual studio, would you know how to fix this or know of a kb article that would help me.

Dan

|||Well, I need for information about the SQL Server: is it 2000, 2005, Express and is it listening on typical port 1433 and can you ping the server from the client using the host name?|||

More info:

stated earlier " I have SQL Server 2000 running on a windows server 2003 machine."

I can ping the server, and yes it's running on 1433 standard port. I still have no connectivity from my workstations for the sql server. Thanks for your help.

|||

It sounds like a security issue then. You may want to try connecting to the server via the client via a tool such as Query Analyzer to determine if your credentials are sufficient to login.

Also, may I ask why you're not using the native ADO.NET SqlClient provider instead?

|||

Please check the following things:

1) what's the protocol enabled on your server? and your client machine? You must have at least on matching protocols on both sides.

2) any firewall on the server? Try disable firewall and do test to isolate the problem. Port 1433 and file sharing should be on the firewall's exception list.

check this blog for more info: http://blogs.msdn.com/sql_protocols

|||

OK here's the problem...

I found out from my lovely network administrator earlier that in fact the service packs weren't installed as she thought. Once these service packs were installed we had access. Don't you just love it when something isn't done that supposed to be.

Thank you though for your help.

Dan

Tuesday, March 20, 2012

OleDB open connection fails for user DSN

Platform: VC 7.0, Windows 2000
Database: SQL Server 2000
Hi,
I created an API, in-proc server, which uses OLEDB to open connection for a
given DSN.
When I create system dsn and execute API from SQL Server Store procedure it
success.
When I create user dsn and execute API from SQL Server Store procedure it
fails and returns error "Data source name not fond and no default driver
specified".
May I know reason for failing API for user DSN? Is there any solution.
Thanks in advance.
Regards
VijayA user DSN is specific to the user logged in... For this to work you must
create a user DSN for the same user that SQL is using ( since you are doing
this in a sp)... Most people would create a System DSN and not even worry
about it though.
--
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"vijay" <vijaysingh@.abo.abosoftware.com> wrote in message
news:u9puL320DHA.4064@.tk2msftngp13.phx.gbl...
> Platform: VC 7.0, Windows 2000
> Database: SQL Server 2000
>
> Hi,
> I created an API, in-proc server, which uses OLEDB to open connection for
a
> given DSN.
>
> When I create system dsn and execute API from SQL Server Store procedure
it
> success.
>
> When I create user dsn and execute API from SQL Server Store procedure it
> fails and returns error "Data source name not fond and no default driver
> specified".
>
> May I know reason for failing API for user DSN? Is there any solution.
>
> Thanks in advance.
>
> Regards
> Vijay
>
>|||How could I decide which DSN should be crated i.e. either system dsn or user
dsn.
Vijay
Sr. Software Engineer
ABO Software
New Delhi
"Wayne Snyder" <wsnyder@.computeredservices.com> wrote in message
news:eS7jFH40DHA.2396@.TK2MSFTNGP09.phx.gbl...
> A user DSN is specific to the user logged in... For this to work you must
> create a user DSN for the same user that SQL is using ( since you are
doing
> this in a sp)... Most people would create a System DSN and not even worry
> about it though.
> --
> Wayne Snyder, MCDBA, SQL Server MVP
> Computer Education Services Corporation (CESC), Charlotte, NC
> www.computeredservices.com
> (Please respond only to the newsgroups.)
> I support the Professional Association of SQL Server (PASS) and it's
> community of SQL Server professionals.
> www.sqlpass.org
>
> "vijay" <vijaysingh@.abo.abosoftware.com> wrote in message
> news:u9puL320DHA.4064@.tk2msftngp13.phx.gbl...
> > Platform: VC 7.0, Windows 2000
> >
> > Database: SQL Server 2000
> >
> >
> >
> > Hi,
> >
> > I created an API, in-proc server, which uses OLEDB to open connection
for
> a
> > given DSN.
> >
> >
> >
> > When I create system dsn and execute API from SQL Server Store procedure
> it
> > success.
> >
> >
> >
> > When I create user dsn and execute API from SQL Server Store procedure
it
> > fails and returns error "Data source name not fond and no default driver
> > specified".
> >
> >
> >
> > May I know reason for failing API for user DSN? Is there any solution.
> >
> >
> >
> > Thanks in advance.
> >
> >
> >
> > Regards
> >
> > Vijay
> >
> >
> >
> >
>

OleDB not returning a empty cursor.

I am using SQLServer 2000 on multiple Windows operating systems and
the application accessing the database are also on multiple Windows
OSs namely Windows 2000 server, Windows 2003 Server, Windows 2000 and
Windows XP. The issue is only noticed when the database resides on
windows 2003 box. The application uses a single connection to call 4
stored procedures sequentially. The first 3 stored procedures do not
return any cursor (just parameter info). But the 4th stored proc is
expected to return a cursor with 0 or more records. When this app is
executed against a SQL server residing on a 2000 server, it returns a
rowset with no rows but all the metadata information is available
(cursor field names).
But in case of Windows 2003 box, when the stored proc has no records
to return (empty cursor), the rowset is set to nil. Basically as part
of the OleDb interface I am calling ICommand
HRESULT Execute (
IUnknown *pUnkOuter,
REFIID riid,
DBPARAMS *pParams,
DBROWCOUNT *pcRowsAffected,
IUnknown **ppRowset);\
In the 2000 server, the IUnknown is a pointer after the execution, but
in 2003, the value is nil. Does anyone know if the SQLServer provider
has been modified to return a nil in case of a empty cursor or is this
a bug? Also if anyone knows of any work arounds or fixes, I would
greatly appreciate it if you could share it with me.
The 2003 box has MDAC 2.8 RTM, while the rest of the boxes have MDAC
2.7x.
Thanks,
SubraSubra (subramanyan.ramanathan@.gmail.com) writes:
> I am using SQLServer 2000 on multiple Windows operating systems and
> the application accessing the database are also on multiple Windows
> OSs namely Windows 2000 server, Windows 2003 Server, Windows 2000 and
> Windows XP. The issue is only noticed when the database resides on
> windows 2003 box. The application uses a single connection to call 4
> stored procedures sequentially. The first 3 stored procedures do not
> return any cursor (just parameter info). But the 4th stored proc is
> expected to return a cursor with 0 or more records. When this app is
> executed against a SQL server residing on a 2000 server, it returns a
> rowset with no rows but all the metadata information is available
> (cursor field names).
> But in case of Windows 2003 box, when the stored proc has no records
> to return (empty cursor), the rowset is set to nil. Basically as part
> of the OleDb interface I am calling ICommand
> HRESULT Execute (
> IUnknown *pUnkOuter,
> REFIID riid,
> DBPARAMS *pParams,
> DBROWCOUNT *pcRowsAffected,
> IUnknown **ppRowset);\
> In the 2000 server, the IUnknown is a pointer after the execution, but
> in 2003, the value is nil. Does anyone know if the SQLServer provider
> has been modified to return a nil in case of a empty cursor or is this
> a bug? Also if anyone knows of any work arounds or fixes, I would
> greatly appreciate it if you could share it with me.
It is not really clear to me. Do you get this problem when you connect
to the SQL Server residing on the Windows 2003 box, no matter which
operating system the client is on?
If that is the case, I can't see that MDAC versions has anything to
do with it, but there is something on the server, that is causing the
NULL pointer.
A few more questions:
o If the stored procedure returns data, do you get a pointer in this
case?
o What is the return code of ICommand::Execute?
o What do you pass for REFIID?
o You talk about cursor. Is that a really true server-side cursor, or
is it just a result set that you get back?
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Thank you for the response.
Yes, the issue happens when I connect to a SQL server residing on a
Windows 2003 box, regardless of the O/s the app is on (have tried
running the app on Windows 2003 and Windows XP).
o If the stored procedure returns data, do you get a pointer in this
case? - Yes, I do get a pointer when a recordset is present.
o What is the return code of ICommand::Execute? - The return code is
0, which means successful
o What do you pass for REFIID? - IID_IUnknown: TGUID =
'{00000000-0000-0000-C000-000000000046}';
o You talk about cursor. Is that a really true server-side cursor,
or
is it just a result set that you get back? - It is just a
resultset.
Thank you.
Subra.
Erland Sommarskog <esquel@.sommarskog.se> wrote in message news:<Xns9599EFD3E715FYazorman@.127
.0.0.1>...
> Subra (subramanyan.ramanathan@.gmail.com) writes:
> It is not really clear to me. Do you get this problem when you connect
> to the SQL Server residing on the Windows 2003 box, no matter which
> operating system the client is on?
> If that is the case, I can't see that MDAC versions has anything to
> do with it, but there is something on the server, that is causing the
> NULL pointer.
> A few more questions:
> o If the stored procedure returns data, do you get a pointer in this
> case?
> o What is the return code of ICommand::Execute?
> o What do you pass for REFIID?
> o You talk about cursor. Is that a really true server-side cursor, or
> is it just a result set that you get back?|||Subra (subramanyan.ramanathan@.gmail.com) writes:
> Thank you for the response.
> Yes, the issue happens when I connect to a SQL server residing on a
> Windows 2003 box, regardless of the O/s the app is on (have tried
> running the app on Windows 2003 and Windows XP).
> o If the stored procedure returns data, do you get a pointer in this
> case? - Yes, I do get a pointer when a recordset is present.
> o What is the return code of ICommand::Execute? - The return code is
> 0, which means successful
> o What do you pass for REFIID? - IID_IUnknown: TGUID =
> '{00000000-0000-0000-C000-000000000046}';
> o You talk about cursor. Is that a really true server-side cursor,
> or
> is it just a result set that you get back? - It is just a
> resultset.
What strikes me as odd is the use if IID_IUnknown. Normally you would
use IID_IRowset or IID_IMultipleResults. I don't know if this has anything
to do with it.
But since the error is independent of which OS the client is on, I am
more inclined to think that there is a difference between the code
running on the two SQL Servers, or the their configuration. I can't
see that the MDAC version should matter.
Could you post the code for the stored procedure? Preferably take it from
the Win2003 database. Also the C++ code from where you create the
command up to the point of execution helps. There are a few variations
with prepared statements, calling syntax etc. It is difficult to recreate
you scenario, without knowing what you are doing.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Erland,
I managed to figure out the issue just recently. The reason for the
issue is that in the stored proc that had the issue, I am using some
temp tables to return data. Supposedly in the newer version of SQL
Server OLEDB provider (SQLOLEDB) they return a result of each
statement that gets executed in the stored proc. This and the
combination of having temp tables in the stored proc results in some
errors and hence no cursor is returned. So the recommended fix for
this issue is to have the setting "SET NOCOUNT ON". I am attaching a
link to the article on the microsoft website.
http://support.microsoft.com/defaul...kb;en-us;235340
Thank you for your assistance.
Regards,
Subra.
Erland Sommarskog <esquel@.sommarskog.se> wrote in message news:<Xns959CD7F71B5EFYazorman@.127
.0.0.1>...
> Subra (subramanyan.ramanathan@.gmail.com) writes:
> What strikes me as odd is the use if IID_IUnknown. Normally you would
> use IID_IRowset or IID_IMultipleResults. I don't know if this has anything
> to do with it.
> But since the error is independent of which OS the client is on, I am
> more inclined to think that there is a difference between the code
> running on the two SQL Servers, or the their configuration. I can't
> see that the MDAC version should matter.
> Could you post the code for the stored procedure? Preferably take it from
> the Win2003 database. Also the C++ code from where you create the
> command up to the point of execution helps. There are a few variations
> with prepared statements, calling syntax etc. It is difficult to recreate
> you scenario, without knowing what you are doing.|||Subra (subramanyan.ramanathan@.gmail.com) writes:
> I managed to figure out the issue just recently. The reason for the
> issue is that in the stored proc that had the issue, I am using some
> temp tables to return data. Supposedly in the newer version of SQL
> Server OLEDB provider (SQLOLEDB) they return a result of each
> statement that gets executed in the stored proc. This and the
> combination of having temp tables in the stored proc results in some
> errors and hence no cursor is returned. So the recommended fix for
> this issue is to have the setting "SET NOCOUNT ON". I am attaching a
> link to the article on the microsoft website.
> http://support.microsoft.com/defaul...kb;en-us;235340
Glad to hear that you were able to resovle the issue!
There is not really any change in the basic behaviour. By default SQL
Server returns a "rows affected" message for each INSERT, DELETE and UPDATE
statement. With most client libraries you get this as count without a result
set. If your code does not handle this, and only looks for the first result
set, all you get is the first "rows affected" message, but no rowset pointer
or the equivalent.
In many cases, these rowcounts are of little interest, so submitting SET
NOCOUNT ON, kills two birds with two stones: you get the data you are
looking for in the first result set, and you improve performance, since
you reduce network traffic.
My recommendation, though, is to use IMultipleResults and get all result
sets, anyway. This makes the code more robust, not the least with regards
to catching errors and PRINT messages.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

Friday, March 30, 2012

One node Cluster for SQL 2005

One ms sql server 2000 instance blocks the other (thru a dts-job)

One more connection problem-Security Issue

Monday, March 26, 2012

Once a week or once a month

Once a week or once a month

Once a week or once a month

Friday, March 23, 2012

OlyMars help?

Wednesday, March 21, 2012

Oleddb dropdown list is empty in Excel

OLEDB question

Tuesday, March 20, 2012

OleDB open connection fails for user DSN

OleDB not returning a empty cursor.

old sql2k5 folder

Blog Archive

About Me