Dual-Core Processors and MS Access?

[Paul]

I've looked all over and haven't been successful in finding an answer to
this, so I thought I'd post here...

Does anyone know if MS Access (2003) is compatible/setup to take advantage
of Dual-Core processing?

I'm looking at spec'ing out a new desktop (Dell 470) and I'm trying to find
out if I'd benefit from the Dual-Core with MS Access. Most all of my DB work
is done in Access (some in PL/SQL and TOAD). I've got an opportunity to
build the 'dream machine' here, so I want to be sure I do that, but I don't
want to go overboard for things that won't be useful with Access.

Thanks for any insight!

 

[xRoachx]

Hi Paul -- I happen to work for one of the well known manufacturers of
dual-core processors. That aside, any high transaction application or db
can take advantage of the dual-core. Hell, IMHO, almost anything can improve
with a dual-core, however, is it worth the cost for what you are doing? IF
you have the chance to build the dream machine, then go for it. I'd would
rather have the extra power and not need it then the other way around.

Unfortunately, I don't have any specific evidence that I can give you...

 

[Paul]

From what I've been able to gather, app's have to be specifically designed to
take advantage of the dual-core processors, if they're not, they won't *see*
them and therefore won't be able to use them to increase the efficiency of
the task at hand.

I regularly query DB's with literally 10's of Millions of records, some with
more than that, and I really need to be able to process faster than I can now.

 

[xRoachx]

I believe you are thinking about 64-bit and not dual core. Applications have
to be designed to take advantage of 64-bit processing but not dual-core.
Dual-core is like having two processors, though it is not a 1-to-1 match.

 

[xRoachx]

Actually, I forgot to mention multi-threading...

To take advantage of the dual-core you do have to use multi-threading so the
application will utilize the dual-core. So my last reply was not completely
accurate.

 

[Jerry Whittle]

Hi Paul,

Consider this: You have the dream machine and develop whizz-bang
applications. Users have plain-jane computers on a network. Guess what can
happen when you put the database out into production? As a developer, you're
better off with a weaker computer as then you know it will work well for the
users. At the very least you want to test your apps on a computer similar to
what the end users have.

 

[Tom Ellison]

Dear Paul:

Not being threaded (split up) for use on more than one processor, Access
cannot benefit directly from this. However, a second processor (in effect)
can perform directory, networking, and other processing required will employ
and benefit from a second processor.

If you use a server database, the server could be multiply threaded, and
could benefit very much from this. This would require research into that
engine. In that situation, Access would not be doing that much processing
(if you use pass-thru queries) and the facility on which much, probably most
of the system time is being spent would benefit from dual processors.

All this is very implementation dependent, enen depending on the methods
employed in your database. I would recommend plenty of memory so the system
is accessing cached data whenever possible. You are then waiting on a
processor (of which you have more) and not on the hard drive. Otherwise,
hard drive performance is more likely to be the key to your performance.

Tom Ellison

 

[Paul]

I'm actually not developing apps for end users. I'm pulling data from
existing DB's for analytical purposes, so in my case, I need the power
(CPU/RAM) to improve the turn around time in which I can obtain and analyze
the data.

Thanks!

 

[Paul]

I recall reading a bit about the 64-bit setup as well. So do you know if
Access '03 is designed for it?

 

[Paul]

The server/network DB's I'm hitting are all running Oracle, but I don't know
their hardware setup.

So if I understand you correctly, with dual-processors the day-to-day
computing requirements can feed off of 1, and Access can use the 2nd 'all to
itself'? I see where if that is the case it would be beneficial.

Regarding memory, I'm looking at 4 GB's, but the Dell 470 can be configured
with up to 16 GB's if necessary. I think 4 should be good though.

Finally as for the drives, the 470 will support SCSI drives and those with
up to 15K RPM's, which doubles the 'normal' 7200RPM's on most newer
desktops/drives. That should help the data access speed as well.

 

[Tom Ellison]

Dear Paul:

If the database is on a server then the issues of processing and memory are
not relative to the workstation (your local computer) but to the server. An
analysis of your requirements may show that you are waiting on the server,
not on the workstation. If that is the case, put your power and money into
the server, not the workstation. The workstation hard drive may have little
or nothing to do with this, unless it is storing some of the results in
local tables.

I recommend you make sure you are using pass-thru queries. Unless you find
a specific reason through analysis of the current bottleneck, I could not
recommend spending any money in the workstation.

Tom Ellison

 

[xRoachx]

I haven't been able to find anything on this as I am just as curious as you.
If I find anything, I'll let you know.

Btw, if you're going to spend a good amount of money through Dell, you might
as well invest in an Alienware (Dell recently purchased them).

 

[Jim Gordon MVP]

Hi Tom & Paul,

If you're not doing some serious number crunching on the workstation I
agree with Tom. Your workstation will be waiting for the server most of
the time.

Connectivity latency will probably be the limiting speed factor, not the
workstation.

Really fast hard drives will probably not make a whole lot of difference
unless your data sets are so large that the drives will be used for
scratch space. More RAM would be a better approach if that's an issue.

-Jim