Numbers of DB in SQL

Is there a limitation of how many db you can have in SQL Standard Edition?
Will it cause problem if we have too much? somewhere around 45 DBs.
Thanks.
The documented limit is 32767 databases per server instance, so you have
some way to go yet! With the appropriate hardware 45 databases is certainly
no problem.
David Portas
SQL Server MVP
|||Thanks for replied my post. My server is a Dell 8450 Quad-processors with 2
GB of RAM.
"David Portas" wrote:

> The documented limit is 32767 databases per server instance, so you have
> some way to go yet! With the appropriate hardware 45 databases is certainly
> no problem.
> --
> David Portas
> SQL Server MVP
> --
>
>
|||David,
I think that when David Portas mentioned "appropriate hardware", he didn't
mean that there's some magic formula for 45 databases. It depends on what
those databases are doing -- how much data they contain, how many users
concurrently use each of them, what those users are doing, etc. If each
database has 100 concurrent users doing million-row queries, you'll quickly
run into a problem. On the other hand, if each database has 1 table with 10
rows of data and has a query run against it once a week, you'll be able to
support thousands of databases
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
"David" <David@.discussions.microsoft.com> wrote in message
news:668C567C-E459-4ABB-A1F7-129BBADD6EB8@.microsoft.com...
> Thanks for replied my post. My server is a Dell 8450 Quad-processors with
2[vbcol=seagreen]
> GB of RAM.
> "David Portas" wrote:
certainly[vbcol=seagreen]
|||David,
In addition to David's and Adam's excellent responses, you may find
limitations with SQL-DMO which will manifest through Enterprise Manager.
After a certain number of databases, you will find that enumeration of
databases will take a long time when you expand the databases node in
the tree. At some point you will find that it takes longer than you are
willing to wait for it, and you will have to administer your databases
using T-SQL.
SMO in SQL Server 2005 addresses this issue by using partial
instantiation (aka delayed instantiation) and caching.
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602m.html
David wrote:
> Is there a limitation of how many db you can have in SQL Standard Edition?
> Will it cause problem if we have too much? somewhere around 45 DBs.
> Thanks.
>
sql

Numbers of DB in SQL

Is there a limitation of how many db you can have in SQL Standard Edition?
Will it cause problem if we have too much? somewhere around 45 DBs.
Thanks.The documented limit is 32767 databases per server instance, so you have
some way to go yet! With the appropriate hardware 45 databases is certainly
no problem.
--
David Portas
SQL Server MVP
--|||Thanks for replied my post. My server is a Dell 8450 Quad-processors with 2
GB of RAM.
"David Portas" wrote:
> The documented limit is 32767 databases per server instance, so you have
> some way to go yet! With the appropriate hardware 45 databases is certainly
> no problem.
> --
> David Portas
> SQL Server MVP
> --
>
>|||David,
I think that when David Portas mentioned "appropriate hardware", he didn't
mean that there's some magic formula for 45 databases. It depends on what
those databases are doing -- how much data they contain, how many users
concurrently use each of them, what those users are doing, etc. If each
database has 100 concurrent users doing million-row queries, you'll quickly
run into a problem. On the other hand, if each database has 1 table with 10
rows of data and has a query run against it once a week, you'll be able to
support thousands of databases :)
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--
"David" <David@.discussions.microsoft.com> wrote in message
news:668C567C-E459-4ABB-A1F7-129BBADD6EB8@.microsoft.com...
> Thanks for replied my post. My server is a Dell 8450 Quad-processors with
2
> GB of RAM.
> "David Portas" wrote:
> > The documented limit is 32767 databases per server instance, so you have
> > some way to go yet! With the appropriate hardware 45 databases is
certainly
> > no problem.
> >
> > --
> > David Portas
> > SQL Server MVP
> > --
> >
> >
> >|||David,
In addition to David's and Adam's excellent responses, you may find
limitations with SQL-DMO which will manifest through Enterprise Manager.
After a certain number of databases, you will find that enumeration of
databases will take a long time when you expand the databases node in
the tree. At some point you will find that it takes longer than you are
willing to wait for it, and you will have to administer your databases
using T-SQL.
SMO in SQL Server 2005 addresses this issue by using partial
instantiation (aka delayed instantiation) and caching.
--
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602m.html
David wrote:
> Is there a limitation of how many db you can have in SQL Standard Edition?
> Will it cause problem if we have too much? somewhere around 45 DBs.
> Thanks.
>

Numbers of DB in SQL

Is there a limitation of how many db you can have in SQL Standard Edition?
Will it cause problem if we have too much? somewhere around 45 DBs.
Thanks.The documented limit is 32767 databases per server instance, so you have
some way to go yet! With the appropriate hardware 45 databases is certainly
no problem.
David Portas
SQL Server MVP
--|||Thanks for replied my post. My server is a Dell 8450 Quad-processors with 2
GB of RAM.
"David Portas" wrote:

> The documented limit is 32767 databases per server instance, so you have
> some way to go yet! With the appropriate hardware 45 databases is certainl
y
> no problem.
> --
> David Portas
> SQL Server MVP
> --
>
>|||David,
I think that when David Portas mentioned "appropriate hardware", he didn't
mean that there's some magic formula for 45 databases. It depends on what
those databases are doing -- how much data they contain, how many users
concurrently use each of them, what those users are doing, etc. If each
database has 100 concurrent users doing million-row queries, you'll quickly
run into a problem. On the other hand, if each database has 1 table with 10
rows of data and has a query run against it once a week, you'll be able to
support thousands of databases
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--
"David" <David@.discussions.microsoft.com> wrote in message
news:668C567C-E459-4ABB-A1F7-129BBADD6EB8@.microsoft.com...
> Thanks for replied my post. My server is a Dell 8450 Quad-processors with
2[vbcol=seagreen]
> GB of RAM.
> "David Portas" wrote:
>
certainly[vbcol=seagreen]|||David,
In addition to David's and Adam's excellent responses, you may find
limitations with SQL-DMO which will manifest through Enterprise Manager.
After a certain number of databases, you will find that enumeration of
databases will take a long time when you expand the databases node in
the tree. At some point you will find that it takes longer than you are
willing to wait for it, and you will have to administer your databases
using T-SQL.
SMO in SQL Server 2005 addresses this issue by using partial
instantiation (aka delayed instantiation) and caching.
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602m.html
David wrote:
> Is there a limitation of how many db you can have in SQL Standard Edition?
> Will it cause problem if we have too much? somewhere around 45 DBs.
> Thanks.
>

Null values cause row height to change

I have a fairly simple report with several columns in the detail section. I
have set the row height to 0.15in (text is 6pt) and set both CanGrow = false
and CanShrink = false for all textboxes in the row.
The report always renders perfectly in the Visual Studio preview tab and
when exporting to PDF, but I run into problems when viewing it on the report
server webpage. Any row with a Null value in one of its fields is rendered
twice as high as the nomal rows. If I change my query so that it doesn't
return nulls, all of the rows render with the same height as expected.
Anyone else run inot this behaviour?I found a cheap way to get around the problem by replacing null values in my
report with a single space. I used expressions like the following:
=iif(IsNothing(Fields!MyField.Value)," ",Fields!MyField.Value)
This is a pain to have to enter in every field though. I would still like to
know a way to get it to render properly in HTML without having to go to all
this trouble.|||there are two options in ADVANCED PROPERTIES of the textbox (or cell of
a table) which meant expand the textbox to accomodate the data and
shrink the textbox to accomodate the data i think by unchecking those
options (ie not allowing shrinking/expansion of textbox) will resolve
the problem check that out n let me know what result comes out
thanx