This question may appear a bit pedestrian but nonetheless.
We are in the process of building OLAP cubes for data analysis purposes. The question that we have is simply can we access the data stored in the OLAP cube in the same way that we would a View. We utilise a simple VB reporting tool that allows us to dynamically interrogate views in our SQL databases. Would this functionality apply also to OLAP.
Regards
RepomanYou can build a cube off of a single table or from a view.
HTH|||I didn't try it yet, but I know that SQL Server has a different OLE DB provider for it's analytical services. You will need to use it to connect to your cube.|||After further research it appears that we cannot just plug directly in. I think we need to use MDX to call the Cube. The resultant data can then be passed to our report builder.
Many thanks for the answers nonetheless.
Regards
Repoman|||Guess I'm not clear on what you are asking. If you build your cubes with ROLAP (relational - OLAP) the cube will build/store your cube in a relational matter. MDX you can use to build calculated members on a cube, what is it you are trying to do?
Showing posts with label bit. Show all posts
Showing posts with label bit. Show all posts
Thursday, March 8, 2012
Friday, February 24, 2012
can an INSERT statement RETURN a value?
I only know a little bit of SQL for Access databases, so sorry if this is a silly question!
Situation: I've to INSERT a new company in a SQL server table named 'companies'. This new company will automatically receive a unique ID (autonumber in Access terminology, don't know how to call it in SQL server)
Question: Can this insert statement return the ID it gave to the company? Or how do I get this ID to use it in an other table?
Thanks in advance!create proc <blah-blah> (@.blah1 varchar(blah), @.blah2 varchar(blah-blah) )
as
declare @.RetVal int, @.Error int
begin tran
insert <blah> (blah1, blah2) values (@.blah1, @.blah2)
select @.Error = @.@.error, @.RetVal = scope_identity()
if @.Error != 0 begin
raiserror ('failed to insert into blah', 16, 1)
rollback tran
return 1
end
commit tran
select NewIdentityValue = @.RetVal
return 0
OR, you can define @.RetVal as output parameter, this way you won't have to do a final SELECT. It's all up to your taste and preference.|||...in other words, NO, it can't, but you can put your Insert statement in a procedure that will return a value or an Output parameter.
blindman|||it actually appears that the answer is YES. explanation blindman?|||We're splitting hairs... yes you can get the ID... from the SELECT statement, no... from a stored procedure... yes...
ClipChips asked if the statement could return the ID. The statement itself cannot. But if you use a SP, you can retrieve it either as a SELECT to a recordset, or an OUTPUT parameter.|||It sounds like the answer is really our favorite "yes and no". Yes, @.@.error acts as a sort of return value, but in the strict definition of a return value, you can not have
exec @.retvalue = "insert into table values (...)" Does that explain it better?|||Yes, No?
You can get Id back without stored procedure!
create table test(id int identity primary key
,code varchar(10))
go
create trigger ins_test on test
for insert
as
select id from inserted
go
insert test values('A')
go
id
----
1
Just get recordset from command object...|||True, but you need a trigger instead.. :)... 6 and half a dozen.. take your pick :)|||Originally posted by Seppuku
True, but you need a trigger instead.. :)... 6 and half a dozen.. take your pick :)
But it is possible... ;)|||you can do it even without a trigger, but from a command object.
create table test1 (f1 int identity(1,1) not null, f2 char(1) not null)
go
Just assign the following command to it:
insert test1 (f2) values ('A') select RetVal=@.@.identity -- or scope_identity() for sql2k
Situation: I've to INSERT a new company in a SQL server table named 'companies'. This new company will automatically receive a unique ID (autonumber in Access terminology, don't know how to call it in SQL server)
Question: Can this insert statement return the ID it gave to the company? Or how do I get this ID to use it in an other table?
Thanks in advance!create proc <blah-blah> (@.blah1 varchar(blah), @.blah2 varchar(blah-blah) )
as
declare @.RetVal int, @.Error int
begin tran
insert <blah> (blah1, blah2) values (@.blah1, @.blah2)
select @.Error = @.@.error, @.RetVal = scope_identity()
if @.Error != 0 begin
raiserror ('failed to insert into blah', 16, 1)
rollback tran
return 1
end
commit tran
select NewIdentityValue = @.RetVal
return 0
OR, you can define @.RetVal as output parameter, this way you won't have to do a final SELECT. It's all up to your taste and preference.|||...in other words, NO, it can't, but you can put your Insert statement in a procedure that will return a value or an Output parameter.
blindman|||it actually appears that the answer is YES. explanation blindman?|||We're splitting hairs... yes you can get the ID... from the SELECT statement, no... from a stored procedure... yes...
ClipChips asked if the statement could return the ID. The statement itself cannot. But if you use a SP, you can retrieve it either as a SELECT to a recordset, or an OUTPUT parameter.|||It sounds like the answer is really our favorite "yes and no". Yes, @.@.error acts as a sort of return value, but in the strict definition of a return value, you can not have
exec @.retvalue = "insert into table values (...)" Does that explain it better?|||Yes, No?
You can get Id back without stored procedure!
create table test(id int identity primary key
,code varchar(10))
go
create trigger ins_test on test
for insert
as
select id from inserted
go
insert test values('A')
go
id
----
1
Just get recordset from command object...|||True, but you need a trigger instead.. :)... 6 and half a dozen.. take your pick :)|||Originally posted by Seppuku
True, but you need a trigger instead.. :)... 6 and half a dozen.. take your pick :)
But it is possible... ;)|||you can do it even without a trigger, but from a command object.
create table test1 (f1 int identity(1,1) not null, f2 char(1) not null)
go
Just assign the following command to it:
insert test1 (f2) values ('A') select RetVal=@.@.identity -- or scope_identity() for sql2k
Thursday, February 16, 2012
Can a rollback be delayed?
Hi all, thanks for reading.
Bit of a puzzler...
A customer of ours has reported a intermittent error using one of our applications to receive some stock.
Under normal circumstances the application updates about 10 tables in a single transaction, inserting to some, updating others. After the stock receipt they print off a Crystal report against the receipt data.
The customer is saying that (very) occasionally they perform a receipt (no errors) and print off the report (no problems) yet when they come to access the data some time later it is almost as if no receipt has been made.
I have seen their data and can see what they mean. None of the expected data updates seem to have taken place. And yet there is the report sat there, indicating that it must have...
Looking closely at the data I can see breaks in the sequencing in certain identity column-carrying tables, during the period when the stock receipt was made. To all intents and purposes, therefore, it looks as though a rollback has occurred.
Is this possible? Could a Crystal report show uncommitted data which is then rolled back? How 'long' can a rollback take? Can it be initiated in some other way?
NB: We have done all the obvious things like:
- checking they have received against the correct DB;
- checking that no app or procedure can remove data in this way.
- verified that the report is reporting from the correct place.
etc.
The 'missing' data is so perfectly removed, my instinct says it must be a rollback but I can't see how this can be (yet).
All suggestions gratefully received - how could I track down whether this was occurring? Or is it my fevered imagination?
Many thanks!!!!
pmb
ps: According to our records, this customer is running SQL 7 SP3.The short answer is "it depends".
The longer (less infuriating) answer is that in order for the rollback to remove the transaction, the transaction must be open during the entire time. This will have the effect that no other SPID can access any of the modified data until the transaction is committed or rolled back (i.e. a blocking problem). OK, sounds like you knew that already, but the practical upshot of all that is that the situation you describe is technically possible provided it all happens on the same connection. If the report is generated from the exact same place (and connection) as the transaction occurred on, then it is possible if one more piece falls exactly into place. The connection must end abnormally without committing the changes. An abnormal end to a connection is generally treated as a rollback, and would explain the situation above, but as I said before, if this was the case, you would very likely see a lot more blocking problems than lost data problems.|||Thanks for the response!
The transactions in our apps are automatically bracketed by 'begin'/'commit transaction' calls as part of screen handling architecture. (ie: the user presses an on-screen button, a 'begin transaction' is fired off, the guts of the program does its SQL business and the final step then fires the 'commit transaction'). Any SQL errors encountered betweentimes are intercepted and displayed to screen (with a 'rollback transaction' performed before program abort).
To the best of my knowledge, no errors are encountered during the stock receipt process, so it looks like the commit goes ok. Following the receipt, the user then spins up our Crystal front-end and runs the relevant report. I would have thought that this Crystal report step would be treated as a completely separate SQL process and thus the report would only be able 'see' the amended data from the previous process once it was committed.
Is there some kind of 'dirty read' (or even 'dirty write') SQL setting that could be happening here? Assuming such a setting exists and is in use here, how would I find out? And how would such logic operate with a rollback?|||It is possible that Crystal Reports is connecting and setting their session to READ_UNCOMMITTED, or using nolock hints, but that would not make a lot of sense (at least to me). You should be able to find out if Crystal is doing that, by running a few Profiler traces.
My money is still on something/someone is deleting the data. It may be via Query Analyzer, rather than through your application, or even an MS Office application accessing the tables directly. From what you say about the architecture of the application, it sounds like the commit/rollback is instantaneous, and does not wait for any user interaction.|||Thanks, fellow drone. Much appreciated. I'll look into the read uncommitted side of things.
On the basis that a report *could* 'see' uncommitted data, I'm still left with the issue of why the rollback is occurring. That's my own problem of course (assuming there is no possibility of this being a SQL server-level issue).
So, a question - if I wrote a trigger to store off transaction details to a logging table (say, writing off @.@.IDENTITY) to 'prove' the reciept was taking place), if a rollback occurs on the triggering table, will my logging table updates also be rolled back?
I'm assuming the answer to the above is 'YES', so am open to suggestions on how to track the problem. (NB: Running Profiler not really an option. On average the issue occurs once a fortnight!)|||That trigger idea made me wonder about something.
create table test1
(col1 int identity (1, 1),
col2 varchar(10))
insert into test1 (col2) values ('hello')
select * from test1
begin transaction
insert into test1 (col2) values ('hi')
select * from test1
begin transaction
update test1
set col2 = 'bye'
commit transaction
select * from test1
rollback transaction
select * from test1
drop table test1
A rollback statement will rollback any transactions committed within any transaction before it. Maybe you should have something check @.@.trancount and save that to a more durable location (say a text log?) Maybe there is some problem when the planets are aligned just right, you have some transaction still going from somewhere else. Still, I would expect that to cause huge blocking problems before lost data problems.
Bit of a puzzler...
A customer of ours has reported a intermittent error using one of our applications to receive some stock.
Under normal circumstances the application updates about 10 tables in a single transaction, inserting to some, updating others. After the stock receipt they print off a Crystal report against the receipt data.
The customer is saying that (very) occasionally they perform a receipt (no errors) and print off the report (no problems) yet when they come to access the data some time later it is almost as if no receipt has been made.
I have seen their data and can see what they mean. None of the expected data updates seem to have taken place. And yet there is the report sat there, indicating that it must have...
Looking closely at the data I can see breaks in the sequencing in certain identity column-carrying tables, during the period when the stock receipt was made. To all intents and purposes, therefore, it looks as though a rollback has occurred.
Is this possible? Could a Crystal report show uncommitted data which is then rolled back? How 'long' can a rollback take? Can it be initiated in some other way?
NB: We have done all the obvious things like:
- checking they have received against the correct DB;
- checking that no app or procedure can remove data in this way.
- verified that the report is reporting from the correct place.
etc.
The 'missing' data is so perfectly removed, my instinct says it must be a rollback but I can't see how this can be (yet).
All suggestions gratefully received - how could I track down whether this was occurring? Or is it my fevered imagination?
Many thanks!!!!
pmb
ps: According to our records, this customer is running SQL 7 SP3.The short answer is "it depends".
The longer (less infuriating) answer is that in order for the rollback to remove the transaction, the transaction must be open during the entire time. This will have the effect that no other SPID can access any of the modified data until the transaction is committed or rolled back (i.e. a blocking problem). OK, sounds like you knew that already, but the practical upshot of all that is that the situation you describe is technically possible provided it all happens on the same connection. If the report is generated from the exact same place (and connection) as the transaction occurred on, then it is possible if one more piece falls exactly into place. The connection must end abnormally without committing the changes. An abnormal end to a connection is generally treated as a rollback, and would explain the situation above, but as I said before, if this was the case, you would very likely see a lot more blocking problems than lost data problems.|||Thanks for the response!
The transactions in our apps are automatically bracketed by 'begin'/'commit transaction' calls as part of screen handling architecture. (ie: the user presses an on-screen button, a 'begin transaction' is fired off, the guts of the program does its SQL business and the final step then fires the 'commit transaction'). Any SQL errors encountered betweentimes are intercepted and displayed to screen (with a 'rollback transaction' performed before program abort).
To the best of my knowledge, no errors are encountered during the stock receipt process, so it looks like the commit goes ok. Following the receipt, the user then spins up our Crystal front-end and runs the relevant report. I would have thought that this Crystal report step would be treated as a completely separate SQL process and thus the report would only be able 'see' the amended data from the previous process once it was committed.
Is there some kind of 'dirty read' (or even 'dirty write') SQL setting that could be happening here? Assuming such a setting exists and is in use here, how would I find out? And how would such logic operate with a rollback?|||It is possible that Crystal Reports is connecting and setting their session to READ_UNCOMMITTED, or using nolock hints, but that would not make a lot of sense (at least to me). You should be able to find out if Crystal is doing that, by running a few Profiler traces.
My money is still on something/someone is deleting the data. It may be via Query Analyzer, rather than through your application, or even an MS Office application accessing the tables directly. From what you say about the architecture of the application, it sounds like the commit/rollback is instantaneous, and does not wait for any user interaction.|||Thanks, fellow drone. Much appreciated. I'll look into the read uncommitted side of things.
On the basis that a report *could* 'see' uncommitted data, I'm still left with the issue of why the rollback is occurring. That's my own problem of course (assuming there is no possibility of this being a SQL server-level issue).
So, a question - if I wrote a trigger to store off transaction details to a logging table (say, writing off @.@.IDENTITY) to 'prove' the reciept was taking place), if a rollback occurs on the triggering table, will my logging table updates also be rolled back?
I'm assuming the answer to the above is 'YES', so am open to suggestions on how to track the problem. (NB: Running Profiler not really an option. On average the issue occurs once a fortnight!)|||That trigger idea made me wonder about something.
create table test1
(col1 int identity (1, 1),
col2 varchar(10))
insert into test1 (col2) values ('hello')
select * from test1
begin transaction
insert into test1 (col2) values ('hi')
select * from test1
begin transaction
update test1
set col2 = 'bye'
commit transaction
select * from test1
rollback transaction
select * from test1
drop table test1
A rollback statement will rollback any transactions committed within any transaction before it. Maybe you should have something check @.@.trancount and save that to a more durable location (say a text log?) Maybe there is some problem when the planets are aligned just right, you have some transaction still going from somewhere else. Still, I would expect that to cause huge blocking problems before lost data problems.
Tuesday, February 14, 2012
Can a 64 bit database be attached to a 32 bit SQL Server?
We are planning to switch our Sql Server 2000 to Sql Server 2005 64 bit
edition. Once I attached the current database to the 64 bit Sql Server and
some changes are made to the database (new records in tables) is it possible
to go back to the 32 bit version of SQL Server with the changed database? I
created a test database on my 64 bit SQL Server, detached it and tried to
attach it to a 32 bit SQL Server. I am getting the following error "Error
602: Could not find row in sysindexes for database ID 10, object ID 1, index
ID 1. Run DBCC CHECKTABLE on sysindexes. Attaching database has failed."
Thank you
Simona wrote:
> We are planning to switch our Sql Server 2000 to Sql Server 2005 64 bit
> edition. Once I attached the current database to the 64 bit Sql Server and
> some changes are made to the database (new records in tables) is it possible
> to go back to the 32 bit version of SQL Server with the changed database? I
> created a test database on my 64 bit SQL Server, detached it and tried to
> attach it to a 32 bit SQL Server. I am getting the following error "Error
> 602: Could not find row in sysindexes for database ID 10, object ID 1, index
> ID 1. Run DBCC CHECKTABLE on sysindexes. Attaching database has failed."
> Thank you
>
You're not only crossing platforms, you're also crossing product
versions. Databases are transportable between platforms (i.e. 64-bit to
32-bit and vice-versa) but not between versions. You can go from SQL
2000 to SQL 2005, but not the reverse.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
edition. Once I attached the current database to the 64 bit Sql Server and
some changes are made to the database (new records in tables) is it possible
to go back to the 32 bit version of SQL Server with the changed database? I
created a test database on my 64 bit SQL Server, detached it and tried to
attach it to a 32 bit SQL Server. I am getting the following error "Error
602: Could not find row in sysindexes for database ID 10, object ID 1, index
ID 1. Run DBCC CHECKTABLE on sysindexes. Attaching database has failed."
Thank you
Simona wrote:
> We are planning to switch our Sql Server 2000 to Sql Server 2005 64 bit
> edition. Once I attached the current database to the 64 bit Sql Server and
> some changes are made to the database (new records in tables) is it possible
> to go back to the 32 bit version of SQL Server with the changed database? I
> created a test database on my 64 bit SQL Server, detached it and tried to
> attach it to a 32 bit SQL Server. I am getting the following error "Error
> 602: Could not find row in sysindexes for database ID 10, object ID 1, index
> ID 1. Run DBCC CHECKTABLE on sysindexes. Attaching database has failed."
> Thank you
>
You're not only crossing platforms, you're also crossing product
versions. Databases are transportable between platforms (i.e. 64-bit to
32-bit and vice-versa) but not between versions. You can go from SQL
2000 to SQL 2005, but not the reverse.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
Can a 64 bit database be attached to a 32 bit SQL Server?
We are planning to switch our Sql Server 2000 to Sql Server 2005 64 bit
edition. Once I attached the current database to the 64 bit Sql Server and
some changes are made to the database (new records in tables) is it possible
to go back to the 32 bit version of SQL Server with the changed database? I
created a test database on my 64 bit SQL Server, detached it and tried to
attach it to a 32 bit SQL Server. I am getting the following error "Error
602: Could not find row in sysindexes for database ID 10, object ID 1, index
ID 1. Run DBCC CHECKTABLE on sysindexes. Attaching database has failed."
Thank youSimona wrote:
> We are planning to switch our Sql Server 2000 to Sql Server 2005 64 bit
> edition. Once I attached the current database to the 64 bit Sql Server and
> some changes are made to the database (new records in tables) is it possib
le
> to go back to the 32 bit version of SQL Server with the changed database?
I
> created a test database on my 64 bit SQL Server, detached it and tried to
> attach it to a 32 bit SQL Server. I am getting the following error "Error
> 602: Could not find row in sysindexes for database ID 10, object ID 1, ind
ex
> ID 1. Run DBCC CHECKTABLE on sysindexes. Attaching database has failed."
> Thank you
>
You're not only crossing platforms, you're also crossing product
versions. Databases are transportable between platforms (i.e. 64-bit to
32-bit and vice-versa) but not between versions. You can go from SQL
2000 to SQL 2005, but not the reverse.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
edition. Once I attached the current database to the 64 bit Sql Server and
some changes are made to the database (new records in tables) is it possible
to go back to the 32 bit version of SQL Server with the changed database? I
created a test database on my 64 bit SQL Server, detached it and tried to
attach it to a 32 bit SQL Server. I am getting the following error "Error
602: Could not find row in sysindexes for database ID 10, object ID 1, index
ID 1. Run DBCC CHECKTABLE on sysindexes. Attaching database has failed."
Thank youSimona wrote:
> We are planning to switch our Sql Server 2000 to Sql Server 2005 64 bit
> edition. Once I attached the current database to the 64 bit Sql Server and
> some changes are made to the database (new records in tables) is it possib
le
> to go back to the 32 bit version of SQL Server with the changed database?
I
> created a test database on my 64 bit SQL Server, detached it and tried to
> attach it to a 32 bit SQL Server. I am getting the following error "Error
> 602: Could not find row in sysindexes for database ID 10, object ID 1, ind
ex
> ID 1. Run DBCC CHECKTABLE on sysindexes. Attaching database has failed."
> Thank you
>
You're not only crossing platforms, you're also crossing product
versions. Databases are transportable between platforms (i.e. 64-bit to
32-bit and vice-versa) but not between versions. You can go from SQL
2000 to SQL 2005, but not the reverse.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
Can 32 bit webserver work with a 64 bit db server?
Is it possble for a W2K3 32-bit webserver running IIS6 access a SQL 2005
server running W2K3 64 bit?
tia
--
MGYes. The SQL Client libraries do not care about the architecture of the
server they connect to. From the client point of view, all SQL Servers are
the same.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Hurme" <michael.geles@.thomson.com> wrote in message
news:82AB06A7-DD7A-46D9-8F0C-F4934C8688C1@.microsoft.com...
> Is it possble for a W2K3 32-bit webserver running IIS6 access a SQL 2005
> server running W2K3 64 bit?
> tia
> --
> MG
server running W2K3 64 bit?
tia
--
MGYes. The SQL Client libraries do not care about the architecture of the
server they connect to. From the client point of view, all SQL Servers are
the same.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Hurme" <michael.geles@.thomson.com> wrote in message
news:82AB06A7-DD7A-46D9-8F0C-F4934C8688C1@.microsoft.com...
> Is it possble for a W2K3 32-bit webserver running IIS6 access a SQL 2005
> server running W2K3 64 bit?
> tia
> --
> MG
Can 32 bit webserver work with a 64 bit db server?
Is it possble for a W2K3 32-bit webserver running IIS6 access a SQL 2005
server running W2K3 64 bit?
tia
MG
Yes. The SQL Client libraries do not care about the architecture of the
server they connect to. From the client point of view, all SQL Servers are
the same.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Hurme" <michael.geles@.thomson.com> wrote in message
news:82AB06A7-DD7A-46D9-8F0C-F4934C8688C1@.microsoft.com...
> Is it possble for a W2K3 32-bit webserver running IIS6 access a SQL 2005
> server running W2K3 64 bit?
> tia
> --
> MG
server running W2K3 64 bit?
tia
MG
Yes. The SQL Client libraries do not care about the architecture of the
server they connect to. From the client point of view, all SQL Servers are
the same.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Hurme" <michael.geles@.thomson.com> wrote in message
news:82AB06A7-DD7A-46D9-8F0C-F4934C8688C1@.microsoft.com...
> Is it possble for a W2K3 32-bit webserver running IIS6 access a SQL 2005
> server running W2K3 64 bit?
> tia
> --
> MG
Can 32 bit SQL 2005 run on a 64 bit processor?
I'm going to be buying a new home PC, and am realizing that many of them now
come in 64 bit. I will of course want to install SQL 2005, but my copy is 32
bit. Also, my copy of Windows XP Pro is 32 bit as well. Should these things
be OK on a 64 bit box?
SQL Server depends on the OS architecture. So, if you are running as 32-bit
OS then the 32-bit version of SQL Server is just fine. Even if you upgrade
your OS to 64-bit you can still use the 32-bit version of SQL Server using
Windows-on-Windows. Also, XP Pro 32-bit will work fine on 64-bit processors.
However, the 32-bit OS cannot take advantage of the 64-bit hardware so you
might look into upgrading to XP 64-bit.
Regards,
Plamen Ratchev
http://www.SQLStudio.com
"ChrisR" <ChrisR@.NoEmail.com> wrote in message
news:epmRRSrIHHA.1504@.TK2MSFTNGP03.phx.gbl...
> I'm going to be buying a new home PC, and am realizing that many of them
> now come in 64 bit. I will of course want to install SQL 2005, but my copy
> is 32 bit. Also, my copy of Windows XP Pro is 32 bit as well. Should these
> things be OK on a 64 bit box?
>
|||Awesome, thanks!
"Plamen Ratchev" <Plamen@.SQLStudio.com> wrote in message
news:O6ea6xrIHHA.1504@.TK2MSFTNGP03.phx.gbl...
> SQL Server depends on the OS architecture. So, if you are running as
> 32-bit OS then the 32-bit version of SQL Server is just fine. Even if you
> upgrade your OS to 64-bit you can still use the 32-bit version of SQL
> Server using Windows-on-Windows. Also, XP Pro 32-bit will work fine on
> 64-bit processors. However, the 32-bit OS cannot take advantage of the
> 64-bit hardware so you might look into upgrading to XP 64-bit.
> Regards,
> Plamen Ratchev
> http://www.SQLStudio.com
>
> "ChrisR" <ChrisR@.NoEmail.com> wrote in message
> news:epmRRSrIHHA.1504@.TK2MSFTNGP03.phx.gbl...
>
come in 64 bit. I will of course want to install SQL 2005, but my copy is 32
bit. Also, my copy of Windows XP Pro is 32 bit as well. Should these things
be OK on a 64 bit box?
SQL Server depends on the OS architecture. So, if you are running as 32-bit
OS then the 32-bit version of SQL Server is just fine. Even if you upgrade
your OS to 64-bit you can still use the 32-bit version of SQL Server using
Windows-on-Windows. Also, XP Pro 32-bit will work fine on 64-bit processors.
However, the 32-bit OS cannot take advantage of the 64-bit hardware so you
might look into upgrading to XP 64-bit.
Regards,
Plamen Ratchev
http://www.SQLStudio.com
"ChrisR" <ChrisR@.NoEmail.com> wrote in message
news:epmRRSrIHHA.1504@.TK2MSFTNGP03.phx.gbl...
> I'm going to be buying a new home PC, and am realizing that many of them
> now come in 64 bit. I will of course want to install SQL 2005, but my copy
> is 32 bit. Also, my copy of Windows XP Pro is 32 bit as well. Should these
> things be OK on a 64 bit box?
>
|||Awesome, thanks!
"Plamen Ratchev" <Plamen@.SQLStudio.com> wrote in message
news:O6ea6xrIHHA.1504@.TK2MSFTNGP03.phx.gbl...
> SQL Server depends on the OS architecture. So, if you are running as
> 32-bit OS then the 32-bit version of SQL Server is just fine. Even if you
> upgrade your OS to 64-bit you can still use the 32-bit version of SQL
> Server using Windows-on-Windows. Also, XP Pro 32-bit will work fine on
> 64-bit processors. However, the 32-bit OS cannot take advantage of the
> 64-bit hardware so you might look into upgrading to XP 64-bit.
> Regards,
> Plamen Ratchev
> http://www.SQLStudio.com
>
> "ChrisR" <ChrisR@.NoEmail.com> wrote in message
> news:epmRRSrIHHA.1504@.TK2MSFTNGP03.phx.gbl...
>
Can 32 bit SQL 2005 run on a 64 bit processor?
I'm going to be buying a new home PC, and am realizing that many of them now
come in 64 bit. I will of course want to install SQL 2005, but my copy is 32
bit. Also, my copy of Windows XP Pro is 32 bit as well. Should these things
be OK on a 64 bit box?SQL Server depends on the OS architecture. So, if you are running as 32-bit
OS then the 32-bit version of SQL Server is just fine. Even if you upgrade
your OS to 64-bit you can still use the 32-bit version of SQL Server using
Windows-on-Windows. Also, XP Pro 32-bit will work fine on 64-bit processors.
However, the 32-bit OS cannot take advantage of the 64-bit hardware so you
might look into upgrading to XP 64-bit.
Regards,
Plamen Ratchev
http://www.SQLStudio.com
"ChrisR" <ChrisR@.NoEmail.com> wrote in message
news:epmRRSrIHHA.1504@.TK2MSFTNGP03.phx.gbl...
> I'm going to be buying a new home PC, and am realizing that many of them
> now come in 64 bit. I will of course want to install SQL 2005, but my copy
> is 32 bit. Also, my copy of Windows XP Pro is 32 bit as well. Should these
> things be OK on a 64 bit box?
>|||Awesome, thanks!
"Plamen Ratchev" <Plamen@.SQLStudio.com> wrote in message
news:O6ea6xrIHHA.1504@.TK2MSFTNGP03.phx.gbl...
> SQL Server depends on the OS architecture. So, if you are running as
> 32-bit OS then the 32-bit version of SQL Server is just fine. Even if you
> upgrade your OS to 64-bit you can still use the 32-bit version of SQL
> Server using Windows-on-Windows. Also, XP Pro 32-bit will work fine on
> 64-bit processors. However, the 32-bit OS cannot take advantage of the
> 64-bit hardware so you might look into upgrading to XP 64-bit.
> Regards,
> Plamen Ratchev
> http://www.SQLStudio.com
>
> "ChrisR" <ChrisR@.NoEmail.com> wrote in message
> news:epmRRSrIHHA.1504@.TK2MSFTNGP03.phx.gbl...
>> I'm going to be buying a new home PC, and am realizing that many of them
>> now come in 64 bit. I will of course want to install SQL 2005, but my
>> copy is 32 bit. Also, my copy of Windows XP Pro is 32 bit as well. Should
>> these things be OK on a 64 bit box?
>|||Hi Chris,
Yes, you can run 32-bit SQL Server on an x64 platform.You can't run
32-bit SQL Server, however, on an Itanium-based platform. The biggest
advantage to running under 64-bit is that you won't have to enable AWE
with the /3GB switch (and /PAE switch on W2K OS). However, you'll
still be limited to 3 GB of RAM for base memory if you're using SQL
Server 2000. If you're using SQL Server 2005 base memory increases to
4 GB unless you're also installing support for CLR, in which case
you'll only have 3 GB for base memory.
You can install XP Pro on an x64 platform as well, but you won't be
able to take advantage of any of the 64-bit functionality mentioned
above. For that, you'll have to spend the bucks to get the 64-bit
version of Windows 2003 Enterprise Edition.
So if all you've got is XP Pro and you plan to install 32-bit
2000/2005, you'd be better off sticking with a 32-bit platform like
the Intel Core Duo. also, if you plan to use this machine as a
database server (as opposed to development) then I'd also suggest
turning off hyperthreading. At high CPU usage the extra work required
to operate the logical CPUs actually decreases overall system
performance.
On Mon, 18 Dec 2006 07:55:26 -0800, "ChrisR" <ChrisR@.NoEmail.com>
wrote:
>I'm going to be buying a new home PC, and am realizing that many of them now
>come in 64 bit. I will of course want to install SQL 2005, but my copy is 32
>bit. Also, my copy of Windows XP Pro is 32 bit as well. Should these things
>be OK on a 64 bit box?
>
come in 64 bit. I will of course want to install SQL 2005, but my copy is 32
bit. Also, my copy of Windows XP Pro is 32 bit as well. Should these things
be OK on a 64 bit box?SQL Server depends on the OS architecture. So, if you are running as 32-bit
OS then the 32-bit version of SQL Server is just fine. Even if you upgrade
your OS to 64-bit you can still use the 32-bit version of SQL Server using
Windows-on-Windows. Also, XP Pro 32-bit will work fine on 64-bit processors.
However, the 32-bit OS cannot take advantage of the 64-bit hardware so you
might look into upgrading to XP 64-bit.
Regards,
Plamen Ratchev
http://www.SQLStudio.com
"ChrisR" <ChrisR@.NoEmail.com> wrote in message
news:epmRRSrIHHA.1504@.TK2MSFTNGP03.phx.gbl...
> I'm going to be buying a new home PC, and am realizing that many of them
> now come in 64 bit. I will of course want to install SQL 2005, but my copy
> is 32 bit. Also, my copy of Windows XP Pro is 32 bit as well. Should these
> things be OK on a 64 bit box?
>|||Awesome, thanks!
"Plamen Ratchev" <Plamen@.SQLStudio.com> wrote in message
news:O6ea6xrIHHA.1504@.TK2MSFTNGP03.phx.gbl...
> SQL Server depends on the OS architecture. So, if you are running as
> 32-bit OS then the 32-bit version of SQL Server is just fine. Even if you
> upgrade your OS to 64-bit you can still use the 32-bit version of SQL
> Server using Windows-on-Windows. Also, XP Pro 32-bit will work fine on
> 64-bit processors. However, the 32-bit OS cannot take advantage of the
> 64-bit hardware so you might look into upgrading to XP 64-bit.
> Regards,
> Plamen Ratchev
> http://www.SQLStudio.com
>
> "ChrisR" <ChrisR@.NoEmail.com> wrote in message
> news:epmRRSrIHHA.1504@.TK2MSFTNGP03.phx.gbl...
>> I'm going to be buying a new home PC, and am realizing that many of them
>> now come in 64 bit. I will of course want to install SQL 2005, but my
>> copy is 32 bit. Also, my copy of Windows XP Pro is 32 bit as well. Should
>> these things be OK on a 64 bit box?
>|||Hi Chris,
Yes, you can run 32-bit SQL Server on an x64 platform.You can't run
32-bit SQL Server, however, on an Itanium-based platform. The biggest
advantage to running under 64-bit is that you won't have to enable AWE
with the /3GB switch (and /PAE switch on W2K OS). However, you'll
still be limited to 3 GB of RAM for base memory if you're using SQL
Server 2000. If you're using SQL Server 2005 base memory increases to
4 GB unless you're also installing support for CLR, in which case
you'll only have 3 GB for base memory.
You can install XP Pro on an x64 platform as well, but you won't be
able to take advantage of any of the 64-bit functionality mentioned
above. For that, you'll have to spend the bucks to get the 64-bit
version of Windows 2003 Enterprise Edition.
So if all you've got is XP Pro and you plan to install 32-bit
2000/2005, you'd be better off sticking with a 32-bit platform like
the Intel Core Duo. also, if you plan to use this machine as a
database server (as opposed to development) then I'd also suggest
turning off hyperthreading. At high CPU usage the extra work required
to operate the logical CPUs actually decreases overall system
performance.
On Mon, 18 Dec 2006 07:55:26 -0800, "ChrisR" <ChrisR@.NoEmail.com>
wrote:
>I'm going to be buying a new home PC, and am realizing that many of them now
>come in 64 bit. I will of course want to install SQL 2005, but my copy is 32
>bit. Also, my copy of Windows XP Pro is 32 bit as well. Should these things
>be OK on a 64 bit box?
>
Can 32 bit SQL 2005 run on a 64 bit processor?
I'm going to be buying a new home PC, and am realizing that many of them now
come in 64 bit. I will of course want to install SQL 2005, but my copy is 32
bit. Also, my copy of Windows XP Pro is 32 bit as well. Should these things
be OK on a 64 bit box?SQL Server depends on the OS architecture. So, if you are running as 32-bit
OS then the 32-bit version of SQL Server is just fine. Even if you upgrade
your OS to 64-bit you can still use the 32-bit version of SQL Server using
Windows-on-Windows. Also, XP Pro 32-bit will work fine on 64-bit processors.
However, the 32-bit OS cannot take advantage of the 64-bit hardware so you
might look into upgrading to XP 64-bit.
Regards,
Plamen Ratchev
http://www.SQLStudio.com
"ChrisR" <ChrisR@.NoEmail.com> wrote in message
news:epmRRSrIHHA.1504@.TK2MSFTNGP03.phx.gbl...
> I'm going to be buying a new home PC, and am realizing that many of them
> now come in 64 bit. I will of course want to install SQL 2005, but my copy
> is 32 bit. Also, my copy of Windows XP Pro is 32 bit as well. Should these
> things be OK on a 64 bit box?
>|||Awesome, thanks!
"Plamen Ratchev" <Plamen@.SQLStudio.com> wrote in message
news:O6ea6xrIHHA.1504@.TK2MSFTNGP03.phx.gbl...
> SQL Server depends on the OS architecture. So, if you are running as
> 32-bit OS then the 32-bit version of SQL Server is just fine. Even if you
> upgrade your OS to 64-bit you can still use the 32-bit version of SQL
> Server using Windows-on-Windows. Also, XP Pro 32-bit will work fine on
> 64-bit processors. However, the 32-bit OS cannot take advantage of the
> 64-bit hardware so you might look into upgrading to XP 64-bit.
> Regards,
> Plamen Ratchev
> http://www.SQLStudio.com
>
> "ChrisR" <ChrisR@.NoEmail.com> wrote in message
> news:epmRRSrIHHA.1504@.TK2MSFTNGP03.phx.gbl...
>
come in 64 bit. I will of course want to install SQL 2005, but my copy is 32
bit. Also, my copy of Windows XP Pro is 32 bit as well. Should these things
be OK on a 64 bit box?SQL Server depends on the OS architecture. So, if you are running as 32-bit
OS then the 32-bit version of SQL Server is just fine. Even if you upgrade
your OS to 64-bit you can still use the 32-bit version of SQL Server using
Windows-on-Windows. Also, XP Pro 32-bit will work fine on 64-bit processors.
However, the 32-bit OS cannot take advantage of the 64-bit hardware so you
might look into upgrading to XP 64-bit.
Regards,
Plamen Ratchev
http://www.SQLStudio.com
"ChrisR" <ChrisR@.NoEmail.com> wrote in message
news:epmRRSrIHHA.1504@.TK2MSFTNGP03.phx.gbl...
> I'm going to be buying a new home PC, and am realizing that many of them
> now come in 64 bit. I will of course want to install SQL 2005, but my copy
> is 32 bit. Also, my copy of Windows XP Pro is 32 bit as well. Should these
> things be OK on a 64 bit box?
>|||Awesome, thanks!
"Plamen Ratchev" <Plamen@.SQLStudio.com> wrote in message
news:O6ea6xrIHHA.1504@.TK2MSFTNGP03.phx.gbl...
> SQL Server depends on the OS architecture. So, if you are running as
> 32-bit OS then the 32-bit version of SQL Server is just fine. Even if you
> upgrade your OS to 64-bit you can still use the 32-bit version of SQL
> Server using Windows-on-Windows. Also, XP Pro 32-bit will work fine on
> 64-bit processors. However, the 32-bit OS cannot take advantage of the
> 64-bit hardware so you might look into upgrading to XP 64-bit.
> Regards,
> Plamen Ratchev
> http://www.SQLStudio.com
>
> "ChrisR" <ChrisR@.NoEmail.com> wrote in message
> news:epmRRSrIHHA.1504@.TK2MSFTNGP03.phx.gbl...
>
Subscribe to:
Posts (Atom)