Showing posts with label restriction. Show all posts
Showing posts with label restriction. Show all posts

Wednesday, March 21, 2012

Question on size restriction for Sql Express and Sql 2005 Standard

If i create a database in SqlEX and then move it to a sever running Sql 2005 standard, am Is my database still limited to the 4GB size?

No, I've tested:

create a database in SQL Express, then detach it;

attach to SQL 2005 Enterprise Edition;

Increase the data file size to 5GB, no problem

Wednesday, March 7, 2012

Question on DRI in Yukon

SQL/Server 2000 has the following restriction (excerpted from BOL):
No table can appear more than once in the list of all cascading referential
actions that result from the DELETE or UPDATE. The tree of cascading
referential actions must not have more than one path to any given table.
The restriction does not exist in Oracle (for example) and I have
encountered many real-life DB design situations where the ability to have
more than one path to a table would be very useful. For example, an m:n
linking table relating two tables that have a common parent table.
Is this restriction lifted in SQL/Server 2005?
Thanks for any input.
Mike A.
Yukon is still in beta under NDA. There should be a public beta released
very soon...
Brian
"Michael Abraham" <mabraham@.decisionarc.com> wrote in message
news:epx2S4bQEHA.624@.TK2MSFTNGP11.phx.gbl...
> SQL/Server 2000 has the following restriction (excerpted from BOL):
> No table can appear more than once in the list of all cascading
referential
> actions that result from the DELETE or UPDATE. The tree of cascading
> referential actions must not have more than one path to any given table.
> The restriction does not exist in Oracle (for example) and I have
> encountered many real-life DB design situations where the ability to have
> more than one path to a table would be very useful. For example, an m:n
> linking table relating two tables that have a common parent table.
> Is this restriction lifted in SQL/Server 2005?
> Thanks for any input.
> Mike A.
>
|||Thanks for the speedy response. I have seen a number of articles on T-SQL
enhancements in Yukon, but none of them were at a sufficiently detailed
level to address my question. I'll just wait (impatiently) for the public
beta.
Mike A.
"Brian Moran" <brian@.solidqualitylearning.com> wrote in message
news:e3AxJ7bQEHA.3124@.TK2MSFTNGP12.phx.gbl...[vbcol=seagreen]
> Yukon is still in beta under NDA. There should be a public beta released
> very soon...
> --
> Brian
> "Michael Abraham" <mabraham@.decisionarc.com> wrote in message
> news:epx2S4bQEHA.624@.TK2MSFTNGP11.phx.gbl...
> referential
have
>

Question on DRI in Yukon

SQL/Server 2000 has the following restriction (excerpted from BOL):
No table can appear more than once in the list of all cascading referential
actions that result from the DELETE or UPDATE. The tree of cascading
referential actions must not have more than one path to any given table.
The restriction does not exist in Oracle (for example) and I have
encountered many real-life DB design situations where the ability to have
more than one path to a table would be very useful. For example, an m:n
linking table relating two tables that have a common parent table.
Is this restriction lifted in SQL/Server 2005?
Thanks for any input.
Mike A.Yukon is still in beta under NDA. There should be a public beta released
very soon...
Brian
"Michael Abraham" <mabraham@.decisionarc.com> wrote in message
news:epx2S4bQEHA.624@.TK2MSFTNGP11.phx.gbl...
> SQL/Server 2000 has the following restriction (excerpted from BOL):
> No table can appear more than once in the list of all cascading
referential
> actions that result from the DELETE or UPDATE. The tree of cascading
> referential actions must not have more than one path to any given table.
> The restriction does not exist in Oracle (for example) and I have
> encountered many real-life DB design situations where the ability to have
> more than one path to a table would be very useful. For example, an m:n
> linking table relating two tables that have a common parent table.
> Is this restriction lifted in SQL/Server 2005?
> Thanks for any input.
> Mike A.
>|||Thanks for the speedy response. I have seen a number of articles on T-SQL
enhancements in Yukon, but none of them were at a sufficiently detailed
level to address my question. I'll just wait (impatiently) for the public
beta.
Mike A.
"Brian Moran" <brian@.solidqualitylearning.com> wrote in message
news:e3AxJ7bQEHA.3124@.TK2MSFTNGP12.phx.gbl...
> Yukon is still in beta under NDA. There should be a public beta released
> very soon...
> --
> Brian
> "Michael Abraham" <mabraham@.decisionarc.com> wrote in message
> news:epx2S4bQEHA.624@.TK2MSFTNGP11.phx.gbl...
> referential
have[vbcol=seagreen]
>

Question on DRI in Yukon

SQL/Server 2000 has the following restriction (excerpted from BOL):
No table can appear more than once in the list of all cascading referential
actions that result from the DELETE or UPDATE. The tree of cascading
referential actions must not have more than one path to any given table.
The restriction does not exist in Oracle (for example) and I have
encountered many real-life DB design situations where the ability to have
more than one path to a table would be very useful. For example, an m:n
linking table relating two tables that have a common parent table.
Is this restriction lifted in SQL/Server 2005?
Thanks for any input.
Mike A.Yukon is still in beta under NDA. There should be a public beta released
very soon...
--
Brian
"Michael Abraham" <mabraham@.decisionarc.com> wrote in message
news:epx2S4bQEHA.624@.TK2MSFTNGP11.phx.gbl...
> SQL/Server 2000 has the following restriction (excerpted from BOL):
> No table can appear more than once in the list of all cascading
referential
> actions that result from the DELETE or UPDATE. The tree of cascading
> referential actions must not have more than one path to any given table.
> The restriction does not exist in Oracle (for example) and I have
> encountered many real-life DB design situations where the ability to have
> more than one path to a table would be very useful. For example, an m:n
> linking table relating two tables that have a common parent table.
> Is this restriction lifted in SQL/Server 2005?
> Thanks for any input.
> Mike A.
>|||Thanks for the speedy response. I have seen a number of articles on T-SQL
enhancements in Yukon, but none of them were at a sufficiently detailed
level to address my question. I'll just wait (impatiently) for the public
beta.
Mike A.
"Brian Moran" <brian@.solidqualitylearning.com> wrote in message
news:e3AxJ7bQEHA.3124@.TK2MSFTNGP12.phx.gbl...
> Yukon is still in beta under NDA. There should be a public beta released
> very soon...
> --
> Brian
> "Michael Abraham" <mabraham@.decisionarc.com> wrote in message
> news:epx2S4bQEHA.624@.TK2MSFTNGP11.phx.gbl...
> > SQL/Server 2000 has the following restriction (excerpted from BOL):
> >
> > No table can appear more than once in the list of all cascading
> referential
> > actions that result from the DELETE or UPDATE. The tree of cascading
> > referential actions must not have more than one path to any given table.
> > The restriction does not exist in Oracle (for example) and I have
> > encountered many real-life DB design situations where the ability to
have
> > more than one path to a table would be very useful. For example, an m:n
> > linking table relating two tables that have a common parent table.
> >
> > Is this restriction lifted in SQL/Server 2005?
> >
> > Thanks for any input.
> >
> > Mike A.
> >
> >
>