HAS MICROSOFT RETIRED SQL SERVER 7.0?

Could you confirm urgently, Microsoft current position on
continued support for SQL Server 7.0.Mainstream support for SQLServer 7.0 ends 31 December 2005.
The product support lifecycle for all Microsoft products is listed here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];lifecycle
--
David Portas
--
Please reply only to the newsgroup
--|||This page lists dates for when server products are 'retired' using your
word...
http://support.microsoft.com/default.aspx?scid=fh;[ln];LifeSrvr
--
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"folajimi" <anonymous@.discussions.microsoft.com> wrote in message
news:077801c3d9bb$13723770$a601280a@.phx.gbl...
> Could you confirm urgently, Microsoft current position on
> continued support for SQL Server 7.0.

HAS MICROSOFT RETIRED SQL SERVER 7.0?

Could you confirm urgently, Microsoft current position on
continued support for SQL Server 7.0.Mainstream support for SQLServer 7.0 ends 31 December 2005.
The product support lifecycle for all Microsoft products is listed here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];lifecycle
David Portas
--
Please reply only to the newsgroup
--|||This page lists dates for when server products are 'retired' using your
word...
http://support.microsoft.com/default.aspx?scid=fh;[ln];LifeSrvr
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"folajimi" <anonymous@.discussions.microsoft.com> wrote in message
news:077801c3d9bb$13723770$a601280a@.phx.gbl...

quote:

---

> Could you confirm urgently, Microsoft current position on
> continued support for SQL Server 7.0.

---

hardware upgrade -> lower "insert" performance

Hey all,
I was about to move my SQL Server from a box that's about four years
old to a current box. The new box should be faster for everything ...
more RAM, faster CPU, faster disks... but the performance of repeated
"insert" statements is measurably worse. The following script took
2:16 on my old hardware (which is running my production system at the
same time), and 3:23 on the new hardware. "select" and "update"
statements do seem to be faster on the new hardware.
Anybody got any clue where I should be looking?
select getdate()
set nocount on
go
if exists
( select *
from sysobjects
where type = 'U'
and name = 'cccInsertTest')
begin
drop table cccInsertTest
end
go
create table cccInsertTest
( a int not null)
go
declare @.i int
select @.i = 0
while @.i < 50000
begin
insert into cccInsertTest (a) values (@.i)
select @.i = @.i + 1
end
go
select getdate()
go
hmmm, is the raid different?
"Chris Curvey" wrote:

> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
>
|||Chris,
A couple of ideas:
Was the test database and log created with enough room so the database and
log didn't have to allocate more space (grow) while the process was running?
Instead of using getdate(), set the statistics time and statistics io
options on (QA Tools/Options, Connection Properties tab). Compare those
metrics instead. Also, run the tests on the servers using Remote Desktop to
eliminate any network transport (should be neglegible, but I'd do it
anyway).
-- Bill
"Chris Curvey" <ccurvey@.gmail.com> wrote in message
news:1170084503.675585.149280@.q2g2000cwa.googlegro ups.com...
> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
>
|||On Jan 29, 10:28 am, "Chris Curvey" <ccur...@.gmail.com> wrote:
> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
>

> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
Turns out that there were two issues. We needed to turn on write
caching within our RAID controller. But the bigger problem was the
client program that we were using to drive the script. "isql" was
running at 4 xacts/sec. "osql" ran at 9 xacts/sec. Writing a Python
script (that ran from another machine, across a slow network link)
gave us 30 xacts/sec.
Go figure!

hardware upgrade -> lower "insert" performance

Hey all,
I was about to move my SQL Server from a box that's about four years
old to a current box. The new box should be faster for everything ...
more RAM, faster CPU, faster disks... but the performance of repeated
"insert" statements is measurably worse. The following script took
2:16 on my old hardware (which is running my production system at the
same time), and 3:23 on the new hardware. "select" and "update"
statements do seem to be faster on the new hardware.
Anybody got any clue where I should be looking?
select getdate()
set nocount on
go
if exists
( select *
from sysobjects
where type = 'U'
and name = 'cccInsertTest')
begin
drop table cccInsertTest
end
go
create table cccInsertTest
( a int not null)
go
declare @.i int
select @.i = 0
while @.i < 50000
begin
insert into cccInsertTest (a) values (@.i)
select @.i = @.i + 1
end
go
select getdate()
gohmmm, is the raid different?
"Chris Curvey" wrote:
> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
>|||Chris,
A couple of ideas:
Was the test database and log created with enough room so the database and
log didn't have to allocate more space (grow) while the process was running?
Instead of using getdate(), set the statistics time and statistics io
options on (QA Tools/Options, Connection Properties tab). Compare those
metrics instead. Also, run the tests on the servers using Remote Desktop to
eliminate any network transport (should be neglegible, but I'd do it
anyway).
-- Bill
"Chris Curvey" <ccurvey@.gmail.com> wrote in message
news:1170084503.675585.149280@.q2g2000cwa.googlegroups.com...
> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
>|||On Jan 29, 10:28 am, "Chris Curvey" <ccur...@.gmail.com> wrote:
> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
>
> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
Turns out that there were two issues. We needed to turn on write
caching within our RAID controller. But the bigger problem was the
client program that we were using to drive the script. "isql" was
running at 4 xacts/sec. "osql" ran at 9 xacts/sec. Writing a Python
script (that ran from another machine, across a slow network link)
gave us 30 xacts/sec.
Go figure!

hardware upgrade -> lower "insert" performance

Hey all,
I was about to move my SQL Server from a box that's about four years
old to a current box. The new box should be faster for everything ...
more RAM, faster CPU, faster disks... but the performance of repeated
"insert" statements is measurably worse. The following script took
2:16 on my old hardware (which is running my production system at the
same time), and 3:23 on the new hardware. "select" and "update"
statements do seem to be faster on the new hardware.
Anybody got any clue where I should be looking?
select getdate()
set nocount on
go
if exists
( select *
from sysobjects
where type = 'U'
and name = 'cccInsertTest')
begin
drop table cccInsertTest
end
go
create table cccInsertTest
( a int not null)
go
declare @.i int
select @.i = 0
while @.i < 50000
begin
insert into cccInsertTest (a) values (@.i)
select @.i = @.i + 1
end
go
select getdate()
gohmmm, is the raid different?
"Chris Curvey" wrote:

> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
>|||Chris,
A couple of ideas:
Was the test database and log created with enough room so the database and
log didn't have to allocate more space (grow) while the process was running?
Instead of using getdate(), set the statistics time and statistics io
options on (QA Tools/Options, Connection Properties tab). Compare those
metrics instead. Also, run the tests on the servers using Remote Desktop to
eliminate any network transport (should be neglegible, but I'd do it
anyway).
-- Bill
"Chris Curvey" <ccurvey@.gmail.com> wrote in message
news:1170084503.675585.149280@.q2g2000cwa.googlegroups.com...
> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
>|||On Jan 29, 10:28 am, "Chris Curvey" <ccur...@.gmail.com> wrote:
> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
>

> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
Turns out that there were two issues. We needed to turn on write
caching within our RAID controller. But the bigger problem was the
client program that we were using to drive the script. "isql" was
running at 4 xacts/sec. "osql" ran at 9 xacts/sec. Writing a Python
script (that ran from another machine, across a slow network link)
gave us 30 xacts/sec.
Go figure!

Hardware Requirements

I suspect that I shouldnt be asking this but ...
I am looking for the current hardware requirements for Yukon. I am
considering purchasing a new server to run a development environment but I
dont know if it will be enough. Can someone help? What are the requirements
for Beta 2?
Thanks. Larry.The requirements are nothing special for Yukon other than Win2003. It will
be more what your app will need to run properly.
Andrew J. Kelly SQL MVP
"Slag" <larry@.krauss.com> wrote in message
news:ea1VSPrAEHA.916@.TK2MSFTNGP10.phx.gbl...
> I suspect that I shouldnt be asking this but ...
> I am looking for the current hardware requirements for Yukon. I am
> considering purchasing a new server to run a development environment but I
> dont know if it will be enough. Can someone help? What are the
requirements
> for Beta 2?
> Thanks. Larry.
>
>|||I don't think looking at the 'minimum' hardware requirements of any database
product will be much help to you.
It's unlikely that Yukon will require any more powerful hardware than SQL
Server 2000 to run applications of similiar size and complexity. You should
feel comfortable sizing your hardware assuming that it will be SQL2000 and
simply upgrade to Yukon when you're ready. Keeping in mind that Yukon is
still many many months from shipping...
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"Slag" <larry@.krauss.com> wrote in message
news:ea1VSPrAEHA.916@.TK2MSFTNGP10.phx.gbl...
> I suspect that I shouldnt be asking this but ...
> I am looking for the current hardware requirements for Yukon. I am
> considering purchasing a new server to run a development environment but I
> dont know if it will be enough. Can someone help? What are the
requirements
> for Beta 2?
> Thanks. Larry.
>
>|||Hi Larry,
Thank you for posting in our community. I believe this is not the appropriat
e
queue to discuss the requirements on Yukon Beta 2, which will walk a long
way to RTM. However, I've really been a pleasure to light you on this topic:
As Brian and Andrew have pointed out, there is no specific hardware
requirements for Yukon, not only Yukon Beta 1 but Beta 2, even Yukon
RTM version or later.
The more important thing is if Yukon is deployed correctly on your machine
and it is integrated closely with Whidbey, which will provided powerful
support for Yukon on its developer tools. So I think what you should care
more is on the software environment on your machine, as making Yukon
work fine is prior to everyting.
Here I introduce some resources for your reference, hoping they will lead
you inside into Yukon:
SQL Server Yukon Solution Development:
http://msdn.microsoft.com/vstudio/p...dmap.aspx#yukon
SQL Server "Yukon":
http://www.microsoft.com/sql/yukon/productinfo/
http://www.microsoft.com/technet/pr...on/default.mspx
Learning About SQL Server "Yukon":
http://msdn.microsoft.com/data/sqls...on/default.aspx
TechNet Webcast: SQL Server Yukon: A First look at the Management
Toolset - Level 200:
http://msevents.microsoft.com/CUI/E...ntID=1032244826
&Culture=en-US
Best regards,
Billy Yao
Microsoft Online Support
----
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only. Thanks.

Hardware Requirements

I suspect that I shouldnt be asking this but ...
I am looking for the current hardware requirements for Yukon. I am
considering purchasing a new server to run a development environment but I
dont know if it will be enough. Can someone help? What are the requirements
for Beta 2?
Thanks. Larry.The requirements are nothing special for Yukon other than Win2003. It will
be more what your app will need to run properly.
--
Andrew J. Kelly SQL MVP
"Slag" <larry@.krauss.com> wrote in message
news:ea1VSPrAEHA.916@.TK2MSFTNGP10.phx.gbl...
> I suspect that I shouldnt be asking this but ...
> I am looking for the current hardware requirements for Yukon. I am
> considering purchasing a new server to run a development environment but I
> dont know if it will be enough. Can someone help? What are the
requirements
> for Beta 2?
> Thanks. Larry.
>
>|||I don't think looking at the 'minimum' hardware requirements of any database
product will be much help to you.
It's unlikely that Yukon will require any more powerful hardware than SQL
Server 2000 to run applications of similiar size and complexity. You should
feel comfortable sizing your hardware assuming that it will be SQL2000 and
simply upgrade to Yukon when you're ready. Keeping in mind that Yukon is
still many many months from shipping...
--
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"Slag" <larry@.krauss.com> wrote in message
news:ea1VSPrAEHA.916@.TK2MSFTNGP10.phx.gbl...
> I suspect that I shouldnt be asking this but ...
> I am looking for the current hardware requirements for Yukon. I am
> considering purchasing a new server to run a development environment but I
> dont know if it will be enough. Can someone help? What are the
requirements
> for Beta 2?
> Thanks. Larry.
>
>|||Hi Larry,
Thank you for posting in our community. I believe this is not the appropriate
queue to discuss the requirements on Yukon Beta 2, which will walk a long
way to RTM. However, I've really been a pleasure to light you on this topic:
As Brian and Andrew have pointed out, there is no specific hardware
requirements for Yukon, not only Yukon Beta 1 but Beta 2, even Yukon
RTM version or later.
The more important thing is if Yukon is deployed correctly on your machine
and it is integrated closely with Whidbey, which will provided powerful
support for Yukon on its developer tools. So I think what you should care
more is on the software environment on your machine, as making Yukon
work fine is prior to everyting.
Here I introduce some resources for your reference, hoping they will lead
you inside into Yukon:
SQL Server Yukon Solution Development:
http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx#yukon
SQL Server "Yukon":
http://www.microsoft.com/sql/yukon/productinfo/
http://www.microsoft.com/technet/prodtechnol/sql/yukon/default.mspx
Learning About SQL Server "Yukon":
http://msdn.microsoft.com/data/sqlsolutions/Yukon/default.aspx
TechNet Webcast: SQL? Server Yukon: A First look at the Management
Toolset - Level 200:
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032244826
&Culture=en-US
Best regards,
Billy Yao
Microsoft Online Support
----
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only. Thanks.