can not find the relationship in 2005

I have a few database that was created in SQL Server 2000.
Now I have 2005 installed and I can see the db:s in SQL Server Management
Studio
But how do I display and edit the relationsships....can not find it here!
Thank you in advance
Mattias
Mattias (Mattias@.discussions.microsoft.com) writes:
> I have a few database that was created in SQL Server 2000.
> Now I have 2005 installed and I can see the db:s in SQL Server Management
> Studio
> But how do I display and edit the relationsships....can not find it here!
Good! That means that you now will have to learn to use CREATE and ALTER
TABLE.
You can get to the Table Designer by right-clicking a table in the Object
Explorer and select New Table or Modify Table. But all the bugs from SQL
2000 are left intact, so I cannot recommend usage of it.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx
|||Hi
Thanks for replying..
Found new table only.......but is this true.
after I have created a "no value" table, where will I be able to
display/edit my "real value" tables relationsships?
Can I remove the new table again?
Ha en bra dag
Mattias Schlipp
"Erland Sommarskog" wrote:

> Mattias (Mattias@.discussions.microsoft.com) writes:
> Good! That means that you now will have to learn to use CREATE and ALTER
> TABLE.
> You can get to the Table Designer by right-clicking a table in the Object
> Explorer and select New Table or Modify Table. But all the bugs from SQL
> 2000 are left intact, so I cannot recommend usage of it.
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/pro...ads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinf...ons/books.mspx
>
|||Hi again
I could modify as well!!
Is it not possible to edit the relationships in a graphical view, using drag
and drop etc.?
Mattias
"Mattias" wrote:
[vbcol=seagreen]
> Hi
> Thanks for replying..
> Found new table only.......but is this true.
> after I have created a "no value" table, where will I be able to
> display/edit my "real value" tables relationsships?
> Can I remove the new table again?
> Ha en bra dag
> Mattias Schlipp
> "Erland Sommarskog" wrote:
|||Mattias (Mattias@.discussions.microsoft.com) writes:
> Is it not possible to edit the relationships in a graphical view, using
> drag and drop etc.?
Try Database Diagrams, and see if you like that sort of thing. But
changing tables through diagrams has the same serious problems as
through Modify Table.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx
|||Hello Erland,
What kind of "serious problems" regarding Modify Table are you referring to?
"Erland Sommarskog" wrote:

> Mattias (Mattias@.discussions.microsoft.com) writes:
> Try Database Diagrams, and see if you like that sort of thing. But
> changing tables through diagrams has the same serious problems as
> through Modify Table.
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/pro...ads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinf...ons/books.mspx
>
|||Jeff B (JeffB@.discussions.microsoft.com) writes:
> What kind of "serious problems" regarding Modify Table are you referring
> to?
I really need to write an article about it, but in the meanwhile a short
summary:
1) The transaction scope is wacko. What should be one transaction is
split up into several, which can lead to a table change being only
partly implemented, and your database becomes a mess. Or you just lose
constraints, without knowing it.
2) In the generated script, the tranxaction spans multiple batches. This
means that if one batch fails with a batch-aborting error, the
transaction is rolled back. The remaining batches in the script are
still carried out which is not likely what you want. (This flaw does
not appear if you save directly, as the Table Designer does not continue
to submit batches if there is an error.)
3) The table designer essentially behaves as there has been no later
version of SQL Server. That is, in many cases where it could use
ALTER TABLE, it instead runs a script where it creates a new table
and copies data over.
4) Say that you have to tables A and B. B has an FK to A. You first make a
change to B, and generate a script. Then you change your mind, and
close without saving anything. Instead you make a change A. When you
generate script (or even worse just press Save), you find that the
change to B is included.
5) All constraints that are reapplied, are reapplied WITH NOCHECK,
which means that they are not trusted as far as the optimizer is
concerned. This have serious impact on performance, not the least
with partitioned views.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx
|||Thanks for the info! I was unaware of most of those issues - those will be
things for me to keep in mind.
Jeff
"Erland Sommarskog" wrote:

> Jeff B (JeffB@.discussions.microsoft.com) writes:
> I really need to write an article about it, but in the meanwhile a short
> summary:
> 1) The transaction scope is wacko. What should be one transaction is
> split up into several, which can lead to a table change being only
> partly implemented, and your database becomes a mess. Or you just lose
> constraints, without knowing it.
> 2) In the generated script, the tranxaction spans multiple batches. This
> means that if one batch fails with a batch-aborting error, the
> transaction is rolled back. The remaining batches in the script are
> still carried out which is not likely what you want. (This flaw does
> not appear if you save directly, as the Table Designer does not continue
> to submit batches if there is an error.)
> 3) The table designer essentially behaves as there has been no later
> version of SQL Server. That is, in many cases where it could use
> ALTER TABLE, it instead runs a script where it creates a new table
> and copies data over.
> 4) Say that you have to tables A and B. B has an FK to A. You first make a
> change to B, and generate a script. Then you change your mind, and
> close without saving anything. Instead you make a change A. When you
> generate script (or even worse just press Save), you find that the
> change to B is included.
> 5) All constraints that are reapplied, are reapplied WITH NOCHECK,
> which means that they are not trusted as far as the optimizer is
> concerned. This have serious impact on performance, not the least
> with partitioned views.
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/pro...ads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinf...ons/books.mspx
>