COl_NAME

Hi there

I'm trying to make some dynamic updated documentation for a MS SQL database, in flash.

So I want to make an SQL which gives the same output as when you look at "Design Table" (Column names, Data type, Lenght, Allow Nulls)

I know how to make a Query for a specific column (COL_NAME) but how do I make a QUERY for all the Columns in a table?

All help is appreciated!!!

Thanks

OISexec sp_columns TableName
may fetch u required result set.

Originally posted by OIS
Hi there

I'm trying to make some dynamic updated documentation for a MS SQL database, in flash.

So I want to make an SQL which gives the same output as when you look at "Design Table" (Column names, Data type, Lenght, Allow Nulls)

I know how to make a Query for a specific column (COL_NAME) but how do I make a QUERY for all the Columns in a table?

All help is appreciated!!!

Thanks

OIS|||This info is stored in sys tables and can be retrieved through the INFORMATION_SCHEMA.Columns view.

select *
from Information_Schema.Columns where Table_Name = #yourtable#

You may also need to specify a TABLE_CATALOG and TABLE_SCHEMA and keep in mind that the information for different data types is stored in different columns of the view.|||Exec sp_Columns is precisly what I was looking for.

Thanks for the help!!!!!

Clustering Reporting Services

Hello,
I'm running a two node cluster, Windows 2003 R2 and SQL 2005. Does anyone
have a white paper or documentation that tells me how to install Reporting
Services as a clustered service? I've never set up a web farm or anyting of
that nature, so any information regarding this would be greatly apprecaited.
Thank you
Alex AndersonI have the same issue here, I'll start installing an active-active cluster
this week and I need to install reporting services on the cluster.
What is the best way to do this.
I asume that reporting services is not cluster aware.
Regards
"Alex Anderson" wrote:
> Hello,
> I'm running a two node cluster, Windows 2003 R2 and SQL 2005. Does anyone
> have a white paper or documentation that tells me how to install Reporting
> Services as a clustered service? I've never set up a web farm or anyting of
> that nature, so any information regarding this would be greatly apprecaited.
> Thank you
> Alex Anderson
>|||Zekske,
What I found out was, depending what version of SQL 2005 you have, I have
standard 2005 which even though SQL is clusterable, reporting services is
not. You will need Enterprise SQL 2005 to be able to cluster reporting
services. I'm just going to run a non-clusterable version of reporting
services.
"Zekske" wrote:
> I have the same issue here, I'll start installing an active-active cluster
> this week and I need to install reporting services on the cluster.
> What is the best way to do this.
> I asume that reporting services is not cluster aware.
> Regards
> "Alex Anderson" wrote:
> > Hello,
> >
> > I'm running a two node cluster, Windows 2003 R2 and SQL 2005. Does anyone
> > have a white paper or documentation that tells me how to install Reporting
> > Services as a clustered service? I've never set up a web farm or anyting of
> > that nature, so any information regarding this would be greatly apprecaited.
> >
> > Thank you
> > Alex Anderson
> >|||OK thanks.
We're installing Enterprise Edition so we'll try the clustering...
Regards
"Alex Anderson" wrote:
> Zekske,
> What I found out was, depending what version of SQL 2005 you have, I have
> standard 2005 which even though SQL is clusterable, reporting services is
> not. You will need Enterprise SQL 2005 to be able to cluster reporting
> services. I'm just going to run a non-clusterable version of reporting
> services.
> "Zekske" wrote:
> > I have the same issue here, I'll start installing an active-active cluster
> > this week and I need to install reporting services on the cluster.
> > What is the best way to do this.
> > I asume that reporting services is not cluster aware.
> > Regards
> >
> > "Alex Anderson" wrote:
> >
> > > Hello,
> > >
> > > I'm running a two node cluster, Windows 2003 R2 and SQL 2005. Does anyone
> > > have a white paper or documentation that tells me how to install Reporting
> > > Services as a clustered service? I've never set up a web farm or anyting of
> > > that nature, so any information regarding this would be greatly apprecaited.
> > >
> > > Thank you
> > > Alex Anderson
> > >

Clustering

I have a question relating more to documentation and support. I'm trying to find documentation on clustering.

I remember quite some time ago I found a white paper that literally walked you through every step involved in setting up a SQL Server failover cluster. I had also found a white paper that walked you through setting up an Active/Active cluster.

I've been going through Microsoft's site, but all I've found are little bits and pieces.

If anyone can point me in the right direction, or even provide a link, etc. as to where to find some good solid documentation, that would be awesome.

Thanks!!

Anthonyhttp://www.dell.com/sql and scroll to the White papers section|||Gracias Amigo!!!!!

Clustered SQL Server 2000 to 2005 Upgrade

I would like to upgrade a production active/passive SQL Server 2000 cluster to SQL Server 2005.

I've read all of the documentation I could find, and doing an in-place upgrade seems to be the way to go. (Despite the fact it scares the hell out of me.

But throughout all the documentation, I've yet to see some simple and fairly important questions answered.

How does the process of upgrading SQL Server work when you're dealing with a cluster?

Do you upgrade one machine then the other? If so, do you upgrade the active node first, or the passive node?

What happens if you're forced to failover from one instance to the other before you've had a chance to upgrade both to 2005? In other words, you failover from 2005 to 2000. Would that even work?

What happens if your upgrades fails for some reason? Is it easy to rollback the installation? If not, will reinstalling SQL Server 2000 cause any issues? Will it remember the previous configuration and simply fix the broken install?

Any help/insight would be greatly appreciated.

Can anybody offer any advice on this?|||Moved to ...Availability forum.|||Maybe I can help. I, along with our network admin, spent a solid 2-3 weeks working on upgrading a active/active cluster to SQL 2005 from 2000. From my experience, it was incredibly simple, yet ridiculously hard. Unless you have every single setting correct on the cluster you will likely run into problems....we did. Here is how we eventually were successful:

1. Fail all active nodes over to one node (I'll call the primary node).
2. Make sure MSDTC is a clustered resource on the cluster. ( we can a test cluster setup and forgot to do this).
3. Install the upgrade to the primary node. There was a little bit of ambiguity when running the install that makes you think that it is going to install it on the 2nd node as well. In my situation, it didnt.
4. After installing on the first node, reboot.
5. Fail over all nodes to the 2ndary node and install the upgrade.
6. Reboot.
7. Failover to primary and install the service pack.
8. Reboot.
9. Failover to the 2ndard and install the service pack.

I am pretty sure these are the steps we followed that worked for us. Most likely, this isn't the recommended course of action of making the upgrade, but it worked. Make sure that when you do install the upgrade, that you install the SQL client tools on the first node. If you don't, you will run into problems later.

If someone else has had a better experience and would like to share their steps to success, please, please do.

Hope this helped,
Tim|||Thanks for your insight. It is incredibly frustrating that there is almost no documentation on this process.

I'm a little confused by your process. You say in step 4 that after you install you should reboot the first node. Does this mean you have downtime or does this cause a failover to other nodes? (I assume it doesn't since you forced the failover to the primary node before starting the process.)

You say in step 5 that you fail over to the secondary node. So this means you're failing over from SQL Server 2005 (on the primary) to SQL Server 2000 (on the secondary). If that works, can we simply fail over to the secondary before we reboot during step 4, thereby avoiding downtime?

Your situation is slightly different than mine since my cluster is active/passive with just two machines. Using your process as a template, mine would look something like:

1.) Install the upgrade on node 1.
2.) Force a failover to node 2 (which is still running SQL Server 2000).
3.) Reboot node 1. Wait for node 1 to restart.
4.) Install the upgrade to node 2.
5.) Force a failover to node 1.
6.) Reboot node 2.

Does this seem correct?
|||

RMD: Did you complete this successfully following your steps? We have the same configuration you do and any previous experience advice would be helpful.

thanks

Clustered SQL Server 2000 to 2005 Upgrade

I would like to upgrade a production active/passive SQL Server 2000 cluster to SQL Server 2005.

I've read all of the documentation I could find, and doing an in-place upgrade seems to be the way to go. (Despite the fact it scares the hell out of me.

But throughout all the documentation, I've yet to see some simple and fairly important questions answered.

How does the process of upgrading SQL Server work when you're dealing with a cluster?

Do you upgrade one machine then the other? If so, do you upgrade the active node first, or the passive node?

What happens if you're forced to failover from one instance to the other before you've had a chance to upgrade both to 2005? In other words, you failover from 2005 to 2000. Would that even work?

What happens if your upgrades fails for some reason? Is it easy to rollback the installation? If not, will reinstalling SQL Server 2000 cause any issues? Will it remember the previous configuration and simply fix the broken install?

Any help/insight would be greatly appreciated.

Can anybody offer any advice on this?|||Moved to ...Availability forum.|||Maybe I can help. I, along with our network admin, spent a solid 2-3 weeks working on upgrading a active/active cluster to SQL 2005 from 2000. From my experience, it was incredibly simple, yet ridiculously hard. Unless you have every single setting correct on the cluster you will likely run into problems....we did. Here is how we eventually were successful:

1. Fail all active nodes over to one node (I'll call the primary node).
2. Make sure MSDTC is a clustered resource on the cluster. ( we can a test cluster setup and forgot to do this).
3. Install the upgrade to the primary node. There was a little bit of ambiguity when running the install that makes you think that it is going to install it on the 2nd node as well. In my situation, it didnt.
4. After installing on the first node, reboot.
5. Fail over all nodes to the 2ndary node and install the upgrade.
6. Reboot.
7. Failover to primary and install the service pack.
8. Reboot.
9. Failover to the 2ndard and install the service pack.

I am pretty sure these are the steps we followed that worked for us. Most likely, this isn't the recommended course of action of making the upgrade, but it worked. Make sure that when you do install the upgrade, that you install the SQL client tools on the first node. If you don't, you will run into problems later.

If someone else has had a better experience and would like to share their steps to success, please, please do.

Hope this helped,
Tim|||Thanks for your insight. It is incredibly frustrating that there is almost no documentation on this process.

I'm a little confused by your process. You say in step 4 that after you install you should reboot the first node. Does this mean you have downtime or does this cause a failover to other nodes? (I assume it doesn't since you forced the failover to the primary node before starting the process.)

You say in step 5 that you fail over to the secondary node. So this means you're failing over from SQL Server 2005 (on the primary) to SQL Server 2000 (on the secondary). If that works, can we simply fail over to the secondary before we reboot during step 4, thereby avoiding downtime?

Your situation is slightly different than mine since my cluster is active/passive with just two machines. Using your process as a template, mine would look something like:

1.) Install the upgrade on node 1.
2.) Force a failover to node 2 (which is still running SQL Server 2000).
3.) Reboot node 1. Wait for node 1 to restart.
4.) Install the upgrade to node 2.
5.) Force a failover to node 1.
6.) Reboot node 2.

Does this seem correct?
|||

RMD: Did you complete this successfully following your steps? We have the same configuration you do and any previous experience advice would be helpful.

thanks

Clustered SQL Server 2000 to 2005 Upgrade

I would like to upgrade a production active/passive SQL Server 2000 cluster to SQL Server 2005.

I've read all of the documentation I could find, and doing an in-place upgrade seems to be the way to go. (Despite the fact it scares the hell out of me.

But throughout all the documentation, I've yet to see some simple and fairly important questions answered.

How does the process of upgrading SQL Server work when you're dealing with a cluster?

Do you upgrade one machine then the other? If so, do you upgrade the active node first, or the passive node?

What happens if you're forced to failover from one instance to the other before you've had a chance to upgrade both to 2005? In other words, you failover from 2005 to 2000. Would that even work?

What happens if your upgrades fails for some reason? Is it easy to rollback the installation? If not, will reinstalling SQL Server 2000 cause any issues? Will it remember the previous configuration and simply fix the broken install?

Any help/insight would be greatly appreciated.

Can anybody offer any advice on this?|||Moved to ...Availability forum.|||Maybe I can help. I, along with our network admin, spent a solid 2-3 weeks working on upgrading a active/active cluster to SQL 2005 from 2000. From my experience, it was incredibly simple, yet ridiculously hard. Unless you have every single setting correct on the cluster you will likely run into problems....we did. Here is how we eventually were successful:

1. Fail all active nodes over to one node (I'll call the primary node).
2. Make sure MSDTC is a clustered resource on the cluster. ( we can a test cluster setup and forgot to do this).
3. Install the upgrade to the primary node. There was a little bit of ambiguity when running the install that makes you think that it is going to install it on the 2nd node as well. In my situation, it didnt.
4. After installing on the first node, reboot.
5. Fail over all nodes to the 2ndary node and install the upgrade.
6. Reboot.
7. Failover to primary and install the service pack.
8. Reboot.
9. Failover to the 2ndard and install the service pack.

I am pretty sure these are the steps we followed that worked for us. Most likely, this isn't the recommended course of action of making the upgrade, but it worked. Make sure that when you do install the upgrade, that you install the SQL client tools on the first node. If you don't, you will run into problems later.

If someone else has had a better experience and would like to share their steps to success, please, please do.

Hope this helped,
Tim|||Thanks for your insight. It is incredibly frustrating that there is almost no documentation on this process.

I'm a little confused by your process. You say in step 4 that after you install you should reboot the first node. Does this mean you have downtime or does this cause a failover to other nodes? (I assume it doesn't since you forced the failover to the primary node before starting the process.)

You say in step 5 that you fail over to the secondary node. So this means you're failing over from SQL Server 2005 (on the primary) to SQL Server 2000 (on the secondary). If that works, can we simply fail over to the secondary before we reboot during step 4, thereby avoiding downtime?

Your situation is slightly different than mine since my cluster is active/passive with just two machines. Using your process as a template, mine would look something like:

1.) Install the upgrade on node 1.
2.) Force a failover to node 2 (which is still running SQL Server 2000).
3.) Reboot node 1. Wait for node 1 to restart.
4.) Install the upgrade to node 2.
5.) Force a failover to node 1.
6.) Reboot node 2.

Does this seem correct?
|||

RMD: Did you complete this successfully following your steps? We have the same configuration you do and any previous experience advice would be helpful.

thanks