Working a new gig, they gave me a pretty nice little workstation,
dual-core 3ghz 2.5gb RAM, don't know what the disk is except it's
80gb.
Anyway, I'm working a GL project where we have to produce about 30m
debits and credits from 2.5m transactions.
The SQL is something like:
select
tranid, x1, a2, gl
into #myfoo
from trantable -- 2.5m rows
cross join xtable -- 12 rows
inner join GLCOA on x1 = a1 -- 300k rows
inner join attribute table on trancode=attribcode -- ten rows
(selecting into the temp just so I don't have to wait for 30m rows to
scroll into query analyzer)
So, guess how long this takes to run, workstation running XP and
SQL2K?
.
.
.
.
Answer: two minutes
Two minutes!?!?
I'm impressed.
When I was a lad, it would have taken quite a while running at 4.77mhz
to generate and write 30m records onto diskettes, I'm just saying, but
even running SQL7 on a 300mhz two-CPU server seven years ago, would
have been easily 10x slower.
I gotta look into the disk config, it's just one drive, this is an HP
workstation.
J.
ps - for all that, the shop is a little chintzy on the monitors, just
a 17 inch 1280x flat panel, OK, but could be better. Not directly a
SQLServer issue. and the mouse has a cord and a ball.On Thu, 16 Nov 2006 22:44:04 -0800, JXStern <JXSternChangeX2R@.gte.net>
wrote:
>So, guess how long this takes to run, workstation running XP and
>SQL2K?
>.
>.
>Answer: two minutes
OK, two and a half.
But even so, isn't anybody else amazed at this?
Perhaps too easily amused,
J.
Showing posts with label workstation. Show all posts
Showing posts with label workstation. Show all posts
Sunday, February 26, 2012
Fast dev workstation!
Working a new gig, they gave me a pretty nice little workstation,
dual-core 3ghz 2.5gb RAM, don't know what the disk is except it's
80gb.
Anyway, I'm working a GL project where we have to produce about 30m
debits and credits from 2.5m transactions.
The SQL is something like:
select
tranid, x1, a2, gl
into #myfoo
from trantable-- 2.5m rows
cross join xtable-- 12 rows
inner join GLCOA on x1 = a1-- 300k rows
inner join attribute table on trancode=attribcode -- ten rows
(selecting into the temp just so I don't have to wait for 30m rows to
scroll into query analyzer)
So, guess how long this takes to run, workstation running XP and
SQL2K?
..
..
..
..
Answer: two minutes
Two minutes!?!?
I'm impressed.
When I was a lad, it would have taken quite a while running at 4.77mhz
to generate and write 30m records onto diskettes, I'm just saying, but
even running SQL7 on a 300mhz two-CPU server seven years ago, would
have been easily 10x slower.
I gotta look into the disk config, it's just one drive, this is an HP
workstation.
J.
ps - for all that, the shop is a little chintzy on the monitors, just
a 17 inch 1280x flat panel, OK, but could be better. Not directly a
SQLServer issue. and the mouse has a cord and a ball.
On Thu, 16 Nov 2006 22:44:04 -0800, JXStern <JXSternChangeX2R@.gte.net>
wrote:
>So, guess how long this takes to run, workstation running XP and
>SQL2K?
>.
>.
>Answer: two minutes
OK, two and a half.
But even so, isn't anybody else amazed at this?
Perhaps too easily amused,
J.
dual-core 3ghz 2.5gb RAM, don't know what the disk is except it's
80gb.
Anyway, I'm working a GL project where we have to produce about 30m
debits and credits from 2.5m transactions.
The SQL is something like:
select
tranid, x1, a2, gl
into #myfoo
from trantable-- 2.5m rows
cross join xtable-- 12 rows
inner join GLCOA on x1 = a1-- 300k rows
inner join attribute table on trancode=attribcode -- ten rows
(selecting into the temp just so I don't have to wait for 30m rows to
scroll into query analyzer)
So, guess how long this takes to run, workstation running XP and
SQL2K?
..
..
..
..
Answer: two minutes
Two minutes!?!?
I'm impressed.
When I was a lad, it would have taken quite a while running at 4.77mhz
to generate and write 30m records onto diskettes, I'm just saying, but
even running SQL7 on a 300mhz two-CPU server seven years ago, would
have been easily 10x slower.
I gotta look into the disk config, it's just one drive, this is an HP
workstation.
J.
ps - for all that, the shop is a little chintzy on the monitors, just
a 17 inch 1280x flat panel, OK, but could be better. Not directly a
SQLServer issue. and the mouse has a cord and a ball.
On Thu, 16 Nov 2006 22:44:04 -0800, JXStern <JXSternChangeX2R@.gte.net>
wrote:
>So, guess how long this takes to run, workstation running XP and
>SQL2K?
>.
>.
>Answer: two minutes
OK, two and a half.
But even so, isn't anybody else amazed at this?
Perhaps too easily amused,
J.
Fast dev workstation!
Working a new gig, they gave me a pretty nice little workstation,
dual-core 3ghz 2.5gb RAM, don't know what the disk is except it's
80gb.
Anyway, I'm working a GL project where we have to produce about 30m
debits and credits from 2.5m transactions.
The SQL is something like:
select
tranid, x1, a2, gl
into #myfoo
from trantable -- 2.5m rows
cross join xtable -- 12 rows
inner join GLCOA on x1 = a1 -- 300k rows
inner join attribute table on trancode=attribcode -- ten rows
(selecting into the temp just so I don't have to wait for 30m rows to
scroll into query analyzer)
So, guess how long this takes to run, workstation running XP and
SQL2K?
.
.
.
.
Answer: two minutes
Two minutes!?!?
I'm impressed.
When I was a lad, it would have taken quite a while running at 4.77mhz
to generate and write 30m records onto diskettes, I'm just saying, but
even running SQL7 on a 300mhz two-CPU server seven years ago, would
have been easily 10x slower.
I gotta look into the disk config, it's just one drive, this is an HP
workstation.
J.
ps - for all that, the shop is a little chintzy on the monitors, just
a 17 inch 1280x flat panel, OK, but could be better. Not directly a
SQLServer issue. and the mouse has a cord and a ball.On Thu, 16 Nov 2006 22:44:04 -0800, JXStern <JXSternChangeX2R@.gte.net>
wrote:
>So, guess how long this takes to run, workstation running XP and
>SQL2K?
>.
>.
>Answer: two minutes
OK, two and a half.
But even so, isn't anybody else amazed at this?
Perhaps too easily amused,
J.
dual-core 3ghz 2.5gb RAM, don't know what the disk is except it's
80gb.
Anyway, I'm working a GL project where we have to produce about 30m
debits and credits from 2.5m transactions.
The SQL is something like:
select
tranid, x1, a2, gl
into #myfoo
from trantable -- 2.5m rows
cross join xtable -- 12 rows
inner join GLCOA on x1 = a1 -- 300k rows
inner join attribute table on trancode=attribcode -- ten rows
(selecting into the temp just so I don't have to wait for 30m rows to
scroll into query analyzer)
So, guess how long this takes to run, workstation running XP and
SQL2K?
.
.
.
.
Answer: two minutes
Two minutes!?!?
I'm impressed.
When I was a lad, it would have taken quite a while running at 4.77mhz
to generate and write 30m records onto diskettes, I'm just saying, but
even running SQL7 on a 300mhz two-CPU server seven years ago, would
have been easily 10x slower.
I gotta look into the disk config, it's just one drive, this is an HP
workstation.
J.
ps - for all that, the shop is a little chintzy on the monitors, just
a 17 inch 1280x flat panel, OK, but could be better. Not directly a
SQLServer issue. and the mouse has a cord and a ball.On Thu, 16 Nov 2006 22:44:04 -0800, JXStern <JXSternChangeX2R@.gte.net>
wrote:
>So, guess how long this takes to run, workstation running XP and
>SQL2K?
>.
>.
>Answer: two minutes
OK, two and a half.
But even so, isn't anybody else amazed at this?
Perhaps too easily amused,
J.
Sunday, February 19, 2012
Failure sending mail: The system cannot find the path specified.
I have had a development XP workstation with RS2000 and IIS sending reports via email for 6 months straight with no problems.
Today my subscriptions are failing with
Been searching and digging for hours, and if anyone has any ideas they are greatly appreciated.
I need some info to troubleshoot...
Replicate the issue, then go the Report Server log (ReportServer_xxx_xxx.log) and email the log to me for review. markcam80@.hotmail.com
What I will be looking for is explicit error messages versus the displayed message.
|||Thanks for the help but it seems we had a domain controller misbehaving.
Subscribe to:
Posts (Atom)