Showing posts with label running. Show all posts
Showing posts with label running. Show all posts

Friday, March 30, 2012

Mdac Xp 2000

My Development machine is Win XP Pro.
I have MDAC 2.7, Visual Studio 6.0 SP3 Installed.

I am running into some issues where a vb program i wrote runs perfectly fine (Using ADO) when connecting to sql server but only runs fine on half of the windows 2000 machines i tested on.

Anyone have any suggestions? even stranger is that the versions of the odbc driver on the 2000 box are newer than the versions on my xp box with MDAC 2.7 SP1 installed.

All machines have DSN's set up exactly the same. I even tested with a DSN'less connection just to be sure (same result).Refer to event viewer logs for any kind of information in this regard.

MDAC upgrade problem CompCheck reports 2.5 instead of 2.8

I am running SQL server on a Windows 2000 server with sp4 installed. After installing SQL service pack 4 on the machine my applications began complaining that MDAC was version 2.5 sure enough CompChecker reports version 2.5. I have tried to install the latest version of MDAC (2.8) on the machine but no matter what I do CompChecker reports 2.5.

I've tried reinstalling the SQL service pack I had no luck with that. Any help with this issue would be greatly appreciated.

WHen was the Windows service pack4 was applied, is it after SQL SP4 or before?

Check this KBA http://support.microsoft.com/kb/823939 for informaiton, ifyou need then you have to install MDAC 2.8 seperately.

|||The service pack was applied before the upgrade.|||I don't know if this helps but I think the issue is with the Windows File Protection. If I attempt to rename one of the dlls the server will automatically replace the file on the server with the 2.5 version. Is there some way to overcome this?|||Did you try to install the MDAC 2.8 separately like Satya proposed ? The file cannot be changed as the Windows FileProtextion is enabled for them (as you already noticed). if you already tried to install the MDAC 2.8, did you get an error or did the install run through ? Did you restart the system afterwards ?

HTH, Jens K. Suessmeyer.


http://www.sqlserver2005.de

|||

I finally figured this out. It turns out that there were certain registry settings that were incorrectly set when SP4 was applied to SQL Server 2000. I don't want to get into the exact registry settings that need to be changed but that is where the answer lies.

Thanks to all for your assistance.

Wednesday, March 28, 2012

MDAC 2.8 Issues?

Most of our Windows 98 SE workstations that are running
MDAC 2.8 have an issue when posting a transaction against
a SQL Server 2000 SP2 database. OLE DB Provider for SQL
Server is the database connector and the application
making the call is coded in Visual Basic 6.1.

The client sees this error returned as an "Runtime 6 -
Overflow Error" on the Visual Basic end as reported by the
OLE DB Provider. Below is a snippet as taken from the SQL
Server Profiler trace:

declare @.P1 int
set @.P1=180150062
declare @.P2 int
set @.P2=2
declare @.P3 int
set @.P3=4
declare @.P4 int
set @.P4=-1
exec sp_cursoropen @.P1 output, N'SELECT TblJobs.[Control
Status Code], TblJobs.[Sales Date], TblJobs.[Promise
Date], TblCust.Last, TblCust.First, TblCust.MI, TblCust.
[Home Phone] FROM TblCust RIGHT JOIN TblJobs ON TblCust.
[Customer ID] = TblJobs.[Customer ID] WHERE TblJobs.
[Control Number] = 00801328', @.P2 output, @.P3 output, @.P4
output
select @.P1, @.P2, @.P3, @.P4

exec sp_cursorfetch 180150062, 32, 1, 1

exec sp_cursorclose 180150062

Error: 2809, Severity: 18, State: 1

Error: 16945, Severity: 16, State: 1

declare @.P1 int
set @.P1=0
declare @.P2 int
set @.P2=229378
declare @.P3 int
set @.P3=294916
declare @.P4 int
set @.P4=0
exec sp_cursoropen @.P1 output, N'exec TblTransactions',
@.P2 output, @.P3 output, @.P4 output
select @.P1, @.P2, @.P3, @.P4

Error: 2809, Severity: 18, State: 1

Error: 16945, Severity: 16, State: 1

Any suggestions? Would using a stored procedure benefit
any? Are there known issues with MDAC 2.8 operating in
this manner? When I rollback to MDAC 2.5 or 2.6 the
operation goes through successfully. I don't relish
rolling back a decent number of client workstations seeing
other MDAC-dependent applications work fine. Unfortunately
I don't have the VB source code to post, so I might be
grasping at straws by posting here.

Any help would be appreciated!Howdy

MDAC 2.8 should really be run against SQL 2000 SP3A - nothing less.
You are running SQL 2000 SP2.

Seems to be lots of problems with SQL 2000 and MDAC & VB ( 6 & .NET )

Cheers,

SG|||I just tested this out by upgrading my local MSDE to sp3a. Restarted and tried the same transaction type and it failed just the same. I really am dreading rolling back all of these workstations, especially since just this one custom app is the one giving me trouble. Wish I myself was a VB programmer so I could dig into things for myself!

Can't imagine something as simple as trying to append a row to an existing set could offer problems. And if MDAC 2.8 is the culprit (since rolling back seems to fix things) I can't imagine no one else piping up about odd MADC 2.8 behavior. Oh well...*sigh*|||Howdy,

It might be worth trying setting nocount on in the sprocs to see what that does...

It may be the "chatter" that the app produces may be causing buffer overflows perhaps. I found setting nocount to on helps with some apps

Cheers,

SG.

Monday, March 26, 2012

mdac 2.6 sp2

Does anyone know any bugs on mdac 2.6 sp2 running on win xp or win98 or win 2000?Do you have to run this version on all 3 operating systems ?

Wednesday, March 21, 2012

MaxInsertCommitSize not found in SQL Server Destination

Hi,

I have installed SQL Server 2005 Service Pack 1 installed. I could see that from running @.@.Version command.

i am not able to find the MaxInsertCommitSize custom property in my sql server destination in SSIS packages.

is there anything specific i need to do to see that.

--

Mahadevan H

That property is not on the SQL Server Destination, it's on the OLE DB Destination.|||

Hi Jwelch,

thank you for your reply. But please refer the following URL from MSDN. It says it is the property of the SQL Destination.

http://msdn2.microsoft.com/en-us/library/ms135971.aspx#sqlserver

Regards

Mahadevan H

|||

h_mahadev wrote:

Hi Jwelch,

thank you for your reply. But please refer the following URL from MSDN. It says it is the property of the SQL Destination.

http://msdn2.microsoft.com/en-us/library/ms135971.aspx#sqlserver

Regards

Mahadevan H

The documentation is correct, it is there. I've pulled a SQL Server Destination into my dataflow, hit F4, and I can see the property in the properties pane.

I'm confused as to why you think it doesn't exist?

-Jamie

|||

Hi,

when i do the same thin i am not getting that property. I am wondering why.

Regards

Mahadevan H

|||

What service pack have you got installed. I am on SP1.

-Jamie

|||SP1 only.|||

h_mahadev wrote:

Hi Jwelch,

thank you for your reply. But please refer the following URL from MSDN. It says it is the property of the SQL Destination.

http://msdn2.microsoft.com/en-us/library/ms135971.aspx#sqlserver

Regards

Mahadevan H

Doh! You are absolutely correct. And, when I rechecked, it is showing up for me as well, just as Jamie mentioned.

If you right-clcik the task, choose Advanced Editor, go to the Component Properties tab, and look in the sction for Custom Properties, does it show up there?

MaximumErrorCount Problem with Copy Database Wizard

I am getting the MaximumErrorCount error when running the Copy Database Wizard. There is an error that I recognize with a stored procedure. I am not interested necessarily in fixing the stored proc error. Rather, I want to just simply copy it "as is" (working in production by the way) and then modify it locally.

I am trying to copy a production database to a develoment environment in order to test against some data. I keep getting the following error:

"The Execution method succeeded, but the number of errors raised (1) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount."

How do I configure the MaximumErrorCount on a particular Copy Database process?

I have looked through the documentation, and have not found any place in the UI to make this change.

I am copying a SQL 2000 db to a SQL 2005 (SP1) instance running on Windows XP SP2.

It makes no sense that I cannot make a configuration as recommended by the error message.

Thanks.

Dennis

I don't think the wizard UI makes this property available. However, if you save the package and open it in BIDS, you can change it there.

Monday, March 12, 2012

Maximum Number of Processes Reached

I am trying to setup transactional replication between Server A and Server B. There are 265 databases on each server.

I am running SQL Server 2005 on Windows Server 2003. The problem comes in at the 201st database. The message in the SQL Server Agent Error Log is :

Warning,[398] The job (WSSWPG09-EmpirePaint-WSSWPG06-104) has been queued because the maximum number of working threads (400) are already running. This job will be executed as soon as one of the working thread finishes execution.

SQL Server's max worker threads is set to 0. The Distribution, LogReader and T-SQL subsystems have been increased to 200 max_worker_threads.

Is there some other setting (maybe a Windows Registry setting) that can be configured to fix this? Or have I just hit a physical maximum of the processor?

Any help is much appreciated.
Maybe engine forum can answer question about max_worker_threads.|||

That is a lot of databases to syncronize between two servers...

Max worker thread set to 0 means use all available threads.

There are 255 threads per logical CPU.

IF you are running out of threads, you may wish to experiment with using 'fibers' (timeslicing the threads).

Go to the Server Properties Window, and on the CPU tab, check 'Use Windows Fibers'.

I recommend testing any changes.

|||

Check out http://www.microsoft.com/technet/technetmag/issues/2006/10/SQLQA/default.aspx

This talks a bit about your issue.

WesleyB

Visit my SQL Server weblog @. http://dis4ea.blogspot.com

Maximum Number of Processes Reached

I am trying to setup transactional replication between Server A and Server B. There are 265 databases on each server.

I am running SQL Server 2005 on Windows Server 2003. The problem comes in at the 201st database. The message in the SQL Server Agent Error Log is :

Warning,[398] The job (WSSWPG09-EmpirePaint-WSSWPG06-104) has been queued because the maximum number of working threads (400) are already running. This job will be executed as soon as one of the working thread finishes execution.

SQL Server's max worker threads is set to 0. The Distribution, LogReader and T-SQL subsystems have been increased to 200 max_worker_threads.

Is there some other setting (maybe a Windows Registry setting) that can be configured to fix this? Or have I just hit a physical maximum of the processor?

Any help is much appreciated.
Maybe engine forum can answer question about max_worker_threads.|||

That is a lot of databases to syncronize between two servers...

Max worker thread set to 0 means use all available threads.

There are 255 threads per logical CPU.

IF you are running out of threads, you may wish to experiment with using 'fibers' (timeslicing the threads).

Go to the Server Properties Window, and on the CPU tab, check 'Use Windows Fibers'.

I recommend testing any changes.

|||

Check out http://www.microsoft.com/technet/technetmag/issues/2006/10/SQLQA/default.aspx

This talks a bit about your issue.

WesleyB

Visit my SQL Server weblog @. http://dis4ea.blogspot.com

Maximum number of databases

Hello everyone -
Running SQL Server 2000
What is the maximum number of databases that can be had in a single MS SQL installation??
thanks
tonyFrom the article titled "Maximum Capacity Specifications" in BOL: 32,767|||If you get close to that you are probably doing something wrong...

Looking at your next thread.... ;)|||I see you are following my thought processes here...

company is approaching 500 databases in a single sql server

not sure on the direction to take or how soon before the ship takes on too much water

thanks for the replies!!

take care
tony

Friday, March 9, 2012

Maximum Memory Settings for Analysis 2005

Dear Anyone,

We have a live machine with an Analysis Services 2005 (32 bit) installed. The machine has been running for a couple of months. They recently upgraded to 8GB (formerly 4GB). It seems that the 32 bit version of MSAS 2005 does not support 8GB or memory. Can anyone please suggest memory settings to maximize the use of the 8GB of memory in the server? Or does anyone know of the maximum memory setup that we can give Analysis Services 2005?

Thanks,

Joseph

AS2K5 is not AWE-aware. As such, its capabilities are based on the underlying OS' virtural address space limitations. The general limits are (32-bit):

2GB -- with an OS that doesn't support the /3GB switch in boot.ini

3GB -- with /3GB enabled in the OS

4GB -- running on an x64 system under WOW

Otherwise, to go more, you need to run in native 64-bit using either x64 or ia64 hardware.

_-_-_ Dave

Maximum memory problem

Hello, everyone:

I have SQL Server 2000 Standard Edition running on Windows 2000 Server. There are always memory full alter. I am going to configure that.

I hope a clearation about a concept. In my enviroment, does SQL Server take maximum memroy upto 2GB, no matter if QWE is enabled?

BOL said AWE is available only in the SQL Server 2000 Enterprise and Developer editions. Does it mean AWE cannot be configured on SQL Server 2000 Standard Edition?

Thanks

ZYTIt's suppose to do that

What? You have other things running on the box?|||Hi, Brett:

No other application is running, only sql server. The physical memory is 4GB. There are alerts. The team in considering to add memory. But it is worried new memory is useless because sql server standard version only take 2GB.

It's suppose to do that

What? You have other things running on the box?|||Yes, AWE cannot be used with SQL Server 2000 Standard Edition. It's limited to 2GB of memory.|||Yes, AWE cannot be used with SQL Server 2000 Standard Edition. It's limited to 2GB of memory.

Not only that, but he's running Windows 2000 Standard. OS Limit is 4GB. No benefit to running AWE on that platform.

AWE is used once you get above 4GB RAM. To get >4 GB RAM, you will need:

Windows 2000 Advanced Server (up to 8 GB RAM)
Windows 2000 Datacenter (Can't remember the limit)
Windows 2003 Enterprise (up to 32 GB RAM)
Windows 2003 Datacenter (up to 64 GB RAM)

Or you could go with Windows 2003 x64 and basically ignore your RAM limits.:shocked:

Regards,

hmscott

Wednesday, March 7, 2012

Maximum Conversation timer interval

I'm using conversation timers successfully to fire events at a predetermined time in the future, but I'm running into issues when using an interval of considerable size. I set the conversation timeout like so:

set @.Timeout = DATEDIFF(SECOND, GETDATE(), DATEADD(MINUTE, -(@.TimeOffset), @.FollowUpDateTime));

if (@.Timeout < 0)

set @.Timeout = 1;

// begin dialog

begin conversation timer (@.FollowUpConversation)

timeout = @.Timeout;

In this case @.Timeout was 94693494.

In the SQL error log I see the following error: "Invalid subcommand value 94693494. Legal range from 1 to 2147483."

I thought I may check the @.Timeout value and simply set it to 2147483 if it is larger than 2147483, but I was wondering if there was a reason the upper limit was so small.

Thanks,

Chris

The upper limit should be 2147483647, max 32 bit integer value, same as the maximum dialog lifetime. The fact that the max value gets divided by 1000 is a defect.

To work around the problem, you can use dialog lifetime instead of dialog timer. I.e. instead of setting a timer on an existing dialog, begin a new dialog with the desired lifetime. Instead of the Timer message, you'll get a Error message that the dialog lifetime has expired. This will give you an upper limit of around 47 years, which I guess is enough.

BTW, since the dialog is errored when the lifetime expires, you must do this on a different dialog that the one on which the document was received in your workflow.

HTH,
~ Remus

|||

Thanks for the reply Remus. I'm hesitant to handle the Error message for the lifetime expired error because I'm hoping that the upper limit for the conversation timer will be addressed in the future and I'd rather not have to refactor that code. I think for now I'll just recalculate the timeout when the dialogtimer message type is handled and reset the timeout if I need to. This raises another question: can I set a conversation lifetime AND a conversation timer on a dialog? I just want to make sure I don't run into a situation where the dialog lifetime expires BEFORE the conversation timer expires.

Thanks again.

|||

Reseting the timer also will work.

All dialogs have a lifetime. If you don't specify one, you'll get the default max lifetime. But the dialog lifetime can only be set at the creation of the dialog (in the BEGIN DIALOG statement) and cannot be changed.

You cannot have the lifetime fire before the timer. Attempting to set the timer beyond lifetime will error the BEGIN DIALOG TIMER statement.

HTH,
~ Remus

|||

Remus,

On a similar note, why wouldn't you specify NO lifetime for all dialogs to ensure that they stay alive long enough to complete? I'm guessing best practice is to specify a lifetime ONLY when you are sure that the process that is spawned will complete within the lifetime you specify, no?

Thanks again,

Chris

|||

Welcome to 'reliable error semantics'.

I'd say that the best practice is to DO specify a lifetime that should cover the maximum allowed time for a business transaction to complete. Usually this lifetime is much longer than the time needed to complete the transaction (including any process this might launch). Typically, the transaction should be complete in a matter of minutes/seconds and the lifetime should cover maybe a day or so. This lifetime would allow for any service unavailability or transmission problems. The question usually raised is 'why not simply rely on en error message to undo the transaction?' If the initiator is tired of waiting and decide to eror the conversation, it could simply use an END CONVERSATION ... WITH ERROR and call it a day. But the problem is what if the initiator can no longer connect itself to the target? How long is the target service supposed to keep the state for this unfinished business transaction? Similarly, what if the host of the initiator is simply stolen or destroyed? Again, how long should the target wait? Having an explicit lifetime puts a limit on this, and most importantly, is a limit on which both the initiator and target agree. If a conversation has expired on one endpoint, you are guaranteed that it expired on the other as weel.

HTH,
~ Remus

|||

Remus,

Thanks for the info, it is of great help. I have just one more question regarding conversation lifetimes: I have multiple service broker services that process a business transaction. Service A sends a message to service B, which sends a message to service C, where a long-running process takes place (anywhere from a few seconds to 15-20 minutes). Is service C, which actually spawns the long-running process, the only conversation that requires a considerable lifetime, or do the services that converse with service C also need a lifetime of equal or greater size than service C? Intuition tells me that the conversation need be open only long enough for the process it spawns to finish, and in the case of services A and B (which perform little business logic and forward the message onto service C) the lifetime can be relatively short.

Thanks for your help,

Chris

|||

In the case when service A has a conversation with service B (we'll call this conversation 'AB') and service B has a related conversation with service C (say 'BC'), then the most generic case should be that the lifetime of 'BC' should be shorter than the lifetime of 'AB'. Probably B cannot send a response to A on 'AB' until it receives the related response from C on 'BC'. If 'AB' expires before C sends the reponse, then there is no reason for C to even bother to send the response. I'm not advocating for B to actualy start making computation of how much from the lifetime of 'AB' has passed when it initiates 'BC' and set a lifetime accordingly. Not that is hard, but I believe this is overkill most cases. But the application designer should consider choosing reasonable lifetimes.

Other case might be when B can send immediatly a response to A: in the same transaction B receives the request from A on 'AB', innitiates 'BC' and sends its own request to C, then ends 'AB' and commits the transactrion. In this case, the lifetimes of 'AB' and 'BC' are completely unrelated.

Also, there might be cases when 'AB' is long lived (days, months, even years) and receives many requests from A to B, while 'BC' is short lived and created from scratch for each individual request from B to C. This is easy to immagine when A and B are in different enterprises and the conversation semantics might have some legal binding contract (e.g the order of requets from A to B must be preserved, therefore all requests must come on the same conversation, think stock trading orders), while B and C are in the same enterprise and requests can be processed in any order.

One other thing the lifetime has to cover is downtime/service unavailability. Having a longer lifetime allows for the targeted service to be unresponsive for a period, or even for the sending service to be unconnected when it creates the conversation. This is why I recommend in general lifetimes of hours or a day.

Without knowing what A/B/C do, I cannot express an opinion on exactly how long the lifetimes should be. But with the cases described above, I think you should be able to make an rational decision.

BTW, in case you're wondering what happens when a request is sent to a service, enqueued, and the lifetime expires before the application actually has a chance to dequeue the request message (is still in the service's queue). The answer is that Error messages are always moved to the top of the queue (for a conversation), so the application will see the Error message first. It can then simply skip the processing of the request. This happens naturally if the application responds to an Error message with and END CONVERSATION, because ending a conversation has the side effect of removing any pending messages from the service queue.

HTH,
~ Remus

P.S. This is a very interesting conversation, it made me think about a couple of issues myself. I'm thinking of posting it as it is into my blog.

|||

Remus,

I should have mentioned that I am not expecting a response from the target queue(s) in this scenario. All of the communication that takes place in our app is one-way with the exception of the EndDialog messages sent to the Initiators (we couldn't think of an appropriate response and we are also using the ServiceBrokerInterface, which meant we didn't want to tie up code waiting on a response when one might not come for quite awhile).

Our scenario is as follows: a trigger or nt service app inserts a message into service A, where it is determined by the message type what to do with it. According to the message type (and more business logic), we send a new message to service B (on a new conversation) and end the conversation started by the initiator. Service B then performs additional processing (based on the message contents) and sends a new message (on a new conversation) to Service C. Service B then ends the conversation started by Service A. Service C runs a stored proc (which can be a long-running process) and ends the conversation initiated by Service B. I've put activated stored procedures in place to handle the EndDialog messages sent to the initiators after reading your "Fire and Forget" article.

Should I use the same conversation throughout the process or is beginning a new conversation each time I send a new message to another service (to process a single entity) OK? I'm beginning to wonder if I should use the converstion handle I create originally throughout the process so that I can requeue the process if any portion of it fails.

This conversation is also making me think as well.

Thanks again,

Chris

|||

If each message sent by A (by the trigger/NT service) is independent, I'd recommend having one dialog per message.

When several messages sent by A are related, then you must send all related messages on one dialog. You would probably need a table on the sender side to locate the appropiate dialog handle.

Since you don't expect replies, the rules are mostly set by the target processing. Because RECEIVE locks the conversation on which it dequeues messages (actually, the conversation group), it means that only one target thread (SPID) can process messages on a given conversation at any moment. The more distinct conversations you have, the higher the degree of paralelism that can be obtained on the target. Also, using separate conversations may be simpler for the sender, as it does not have to look up and find a conversation handle, it can simply create a new one each time.

One think to keep in mind though is that one conversation per message requires more resources for each message sent. The set-up and tear-down of a conversation is not free, it involves:
- creation of initiator endpoint
- creation of target endpoint
- one EndDialog message
- one acknoledgement message for the EndDialog message
- deletion of initiator endpoint
- deletion of target endpoint
All these operations are causing log writes and database updates and/or network traffic. When more messages are sent per one conversation, this cost is ammortized over all the messages sent. If only one message is is sent per conversation, all this cost goes into the one message sent, so sending a message is more expensive (from a resouce point of view). All these speel that reusing conversations might give some performance gains.

But I must stress that you should carefully consider the simplicity of the one message per conversation vs. the performance gains of multiple messages per conversation. If your expected traffic involves say 10 messages per second, then is hardly worth looking into the benefits of reusing conversations. But if you aim for 5000 messages per second, then you should probably seriously consider the cost of beginning/ending a dialog.

And, again, if the messages are related, then most likely you have to send them on the same conversation.

HTH,
~ Remus

Maximum connections for SQL 2000 Developer Edition

I can't seem to find this info online anywhere. What's
the maximum connections for SQL 2000 Developer Edition?
We have a server running several instances of Developer
edition so does they have the share these connections or
is it a max connections per instance?
Thanks,
Van
Hi
Technically 32 737 per instance, but you will run out of TCP ports long
before a multi-instance installation can max out.
Developer Edition is Enterprise Edition with licensing limitations.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Van Jones" <anonymous@.discussions.microsoft.com> wrote in message
news:129201c55266$1fbd2b00$a601280a@.phx.gbl...
>I can't seem to find this info online anywhere. What's
> the maximum connections for SQL 2000 Developer Edition?
> We have a server running several instances of Developer
> edition so does they have the share these connections or
> is it a max connections per instance?
> Thanks,
> Van

Maximum Capacity supported by SQL Server 2000 Enterprise under Windows Server 2003 Enterprise

Hello

Does anyone know what is the maximum capacity supported by SQL Server 2000 Enterprise Edition running under Windows Server 2003 Enterprise Edition in terms of number of CPU and amount of RAM.?

For CPU : Windows Server 2003 EE supported up to 8 CPU so I assume SQL 2000 Enterprise can also support up to 8 CPU

For memory: Windows Server 2003 EE (32 bits) can support up to 32 GB of RAM so I am wondering whether SQL 2000 EE can also support up to 32 GB ? Under BOL it said it could support up to 8 GB of RAM under Windows 2000 Advance server but it does not mention Windows Server 2003 EE?

Hi Kay. SQL Server support for memory and CPU generally follows the same supported limits for the OS it is running on. Which means for memory, SQL Server supports the use of up to 32gb of RAM on Windows 2003 Enterprise, and up to 64gb of RAM with Windows 2003 Datacenter. For CPU, Windows Server 2003 Enterprise pushes up to at least 16 CPUs I believe, possibly 32 now...perhaps someone else can verify this for sure, but I believe those are the correct numbers.

HTH

|||

Hi Chad.

I found a reference at the Microsoft Web site on Windows Server 2003 comparions. It seems to indicate that Enterprise Edition only supports up to 8-way (for both SP1 and R2) for processor. For memory it can support up to 64 GB in RAM and 1 TB for x64 and Itanium versions.

http://www.microsoft.com/windowsserver2003/evaluation/features/comparefeatures.mspx#Hardware%20Specifications

Thanks for your answer on the questions regarding the memory supported by SQL. I am planning to upgrade our server to max CPU & RAM and I want to make sure that SQL can take the advantage of the additional hardware.