Multiple IP's. Only want 1 for SQL 1433

Hi,
I've got an SQL server 2000 (sp3).
This box has multiple IP addresses. These are for web pages
But i only want the SQL server (port 1433) to listen on one of these addressses.
It seems to listen on all the addresses which i don't want it to. for sercuirty reasons as well
as for it's resource sake.
I've poked around in the properties and connection settings and it doesn't seem to let you change IP's only ports etc.
Please let me know how i can work this out..
Thankyou
There is no way to prevent SQL Server from listening on all the ip
addresses that are bound to NIC cards on the machine. If you want to limit
the ones that clients can connect to then that will have to be impletmented
at the client level.
Rand
This posting is provided "as is" with no warranties and confers no rights.

Multiple IP's. Only want 1 for SQL 1433

Hi,
I've got an SQL server 2000 (sp3).
This box has multiple IP addresses. These are for web pages
But i only want the SQL server (port 1433) to listen on one of these address
ses.
It seems to listen on all the addresses which i don't want it to. for sercui
rty reasons as well
as for it's resource sake.
I've poked around in the properties and connection settings and it doesn't s
eem to let you change IP's only ports etc.
Please let me know how i can work this out..
ThankyouThere is no way to prevent SQL Server from listening on all the ip
addresses that are bound to NIC cards on the machine. If you want to limit
the ones that clients can connect to then that will have to be impletmented
at the client level.
Rand
This posting is provided "as is" with no warranties and confers no rights.

Multiple Databases vs a Few

I started work a new company recently and they provide a web based tool to
companies. The database model is in rough shape -- when a new client comes
on they simply create a new database for each client. Right now they have
roughly 400+ databases split over two database servers.
I am suggesting they bring that # down to a couple. I think managing 400
connections to a variety of databases might be a performance concern. I
would also think that in terms of Stored Procs it must be using more
resources -- instead of optimizing 1 it has to optimize the same 1, 400
times.
Im guessing on those above -- does anyone know the postive and negatives in
doing this, or know of any article discussing this topic.
Thanks
Brian wrote:
> I started work a new company recently and they provide a web based
> tool to companies. The database model is in rough shape -- when a
> new client comes on they simply create a new database for each
> client. Right now they have roughly 400+ databases split over two
> database servers.
> I am suggesting they bring that # down to a couple. I think managing
> 400 connections to a variety of databases might be a performance
> concern. I would also think that in terms of Stored Procs it must
> be using more resources -- instead of optimizing 1 it has to optimize
> the same 1, 400 times.
> Im guessing on those above -- does anyone know the postive and
> negatives in doing this, or know of any article discussing this topic.
> Thanks
I don't necessarily think using separate databases is an architectural
problem. It does, however, lead to more involved backups and SP
management. OTOH, the databases are smaller, can be backed up more
quickly, and different databases offers a level of security that might
be more difficult to manage should all clients be combined into the same
tables in the same database. What happens when a client leaves? How
involved is the removal of data if they share tables? What happens if
one client's data is accidentally shown as being "owned" by another
client? Does that lead to potential legal concerns... You get the idea.
The architecture, it seems, may need to involve legal as well as IT.
Your comments about SP duplication, however, is a concern. Certainly, if
you could find a way to share all common procedures, it would help
maintenance. You could consider using a shared database for all (most)
stored procedure access. That should allow you to use a single set of
procs for all user databases. Instead of executing the procedure in the
current database, just prefix the shared db (shareddb.dbo.procname).
David Gugick
Imceda Software
www.imceda.com
|||Brian
There are no reasons to create a database for each client. I think you are
going to build a new model of the database , only you do know a business
requrements.
Visit at www.sql-server_performance.com and you will find a really good
stuff there.
"Brian" <brian@.nospam.com> wrote in message
news:%23k$J8cpuEHA.3808@.TK2MSFTNGP10.phx.gbl...
> I started work a new company recently and they provide a web based tool to
> companies. The database model is in rough shape -- when a new client
comes
> on they simply create a new database for each client. Right now they have
> roughly 400+ databases split over two database servers.
> I am suggesting they bring that # down to a couple. I think managing 400
> connections to a variety of databases might be a performance concern. I
> would also think that in terms of Stored Procs it must be using more
> resources -- instead of optimizing 1 it has to optimize the same 1, 400
> times.
> Im guessing on those above -- does anyone know the postive and negatives
in
> doing this, or know of any article discussing this topic.
> Thanks
>
|||It is an administrator's nightmare. However, if the DBs for each of your
clients has data related to that specific client and should not be mixed
with other clients (which is correct) then I guess, you will have to live
with it. If the DBs contain code and metadata for your web based client
application, then consolidating is the right approach.
"Brian" <brian@.nospam.com> wrote in message
news:#k$J8cpuEHA.3808@.TK2MSFTNGP10.phx.gbl...
> I started work a new company recently and they provide a web based tool to
> companies. The database model is in rough shape -- when a new client
comes
> on they simply create a new database for each client. Right now they have
> roughly 400+ databases split over two database servers.
> I am suggesting they bring that # down to a couple. I think managing 400
> connections to a variety of databases might be a performance concern. I
> would also think that in terms of Stored Procs it must be using more
> resources -- instead of optimizing 1 it has to optimize the same 1, 400
> times.
> Im guessing on those above -- does anyone know the postive and negatives
in
> doing this, or know of any article discussing this topic.
> Thanks
>
|||Have you considered using partitioned views to unify all this data in a
common DB? Using that method you may only need a single copy of much of your
server-side code.
I would have expected that the main argument for unifying the databases into
one would be based on the potential savings on development, reporting and
admin costs over the costs of those things for 100s of identical databases.
David Portas
SQL Server MVP
|||There is little to no difference between the databases. A couple clients
have a few custom pieces but nothing that could not be solved in the data
model.
Aside from the admin nightmare (it exists now), is there any performance
hit. I guess this may be more is an IIS webserver question. Having to
manage 400 different connection strings.
And again the duplicate Stored Procs, and who knows what else.
"Bhanu" <SQLDBA1999@.yahoo.com> wrote in message
news:uwhvCspuEHA.2144@.tk2msftngp13.phx.gbl...
> It is an administrator's nightmare. However, if the DBs for each of your
> clients has data related to that specific client and should not be mixed
> with other clients (which is correct) then I guess, you will have to live
> with it. If the DBs contain code and metadata for your web based client
> application, then consolidating is the right approach.
>
>
> "Brian" <brian@.nospam.com> wrote in message
> news:#k$J8cpuEHA.3808@.TK2MSFTNGP10.phx.gbl...
> comes
> in
>
|||Hi Brian,
I am a dba for multiple companies in a datacenter and one of our companies
has around 400 lawfirms and everything is in one database. The main thing
that you have to think about is security. In our case each lawfirm has a role
and many tables contain a field that specifies to which law firm the row
belongs (row level security). This is basically the idea but it gets more
complex when you have multiple groups with each law firm. This is based on
the requirements and something that you have to analyze). If it was me, I
would create one database with 2 clients and test the crap out of it... The
process might be painful but you have a lot to win as a DBA (amount of work
for you and the developers, $$$, more simplified disaster recovery
process...).
Sasan Saidi, MSc. in CS
"Brian" wrote:

> I started work a new company recently and they provide a web based tool to
> companies. The database model is in rough shape -- when a new client comes
> on they simply create a new database for each client. Right now they have
> roughly 400+ databases split over two database servers.
> I am suggesting they bring that # down to a couple. I think managing 400
> connections to a variety of databases might be a performance concern. I
> would also think that in terms of Stored Procs it must be using more
> resources -- instead of optimizing 1 it has to optimize the same 1, 400
> times.
> Im guessing on those above -- does anyone know the postive and negatives in
> doing this, or know of any article discussing this topic.
> Thanks
>
>
|||Hi Brian,
I have noticed Peter and Sasan Saidi had given their suggestions on this
issue. I wanted to post a quick note to see if you would like additional
assistance or information regarding this particular issue. We appreciate
your patience and look forward to hearing from you!
Sincerely yours,
Michael Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Get Secure! - http://www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!

Multiple Databases vs a Few

I started work a new company recently and they provide a web based tool to
companies. The database model is in rough shape -- when a new client comes
on they simply create a new database for each client. Right now they have
roughly 400+ databases split over two database servers.
I am suggesting they bring that # down to a couple. I think managing 400
connections to a variety of databases might be a performance concern. I
would also think that in terms of Stored Procs it must be using more
resources -- instead of optimizing 1 it has to optimize the same 1, 400
times.
Im guessing on those above -- does anyone know the postive and negatives in
doing this, or know of any article discussing this topic.
ThanksBrian wrote:
> I started work a new company recently and they provide a web based
> tool to companies. The database model is in rough shape -- when a
> new client comes on they simply create a new database for each
> client. Right now they have roughly 400+ databases split over two
> database servers.
> I am suggesting they bring that # down to a couple. I think managing
> 400 connections to a variety of databases might be a performance
> concern. I would also think that in terms of Stored Procs it must
> be using more resources -- instead of optimizing 1 it has to optimize
> the same 1, 400 times.
> Im guessing on those above -- does anyone know the postive and
> negatives in doing this, or know of any article discussing this topic.
> Thanks
I don't necessarily think using separate databases is an architectural
problem. It does, however, lead to more involved backups and SP
management. OTOH, the databases are smaller, can be backed up more
quickly, and different databases offers a level of security that might
be more difficult to manage should all clients be combined into the same
tables in the same database. What happens when a client leaves? How
involved is the removal of data if they share tables? What happens if
one client's data is accidentally shown as being "owned" by another
client? Does that lead to potential legal concerns... You get the idea.
The architecture, it seems, may need to involve legal as well as IT.
Your comments about SP duplication, however, is a concern. Certainly, if
you could find a way to share all common procedures, it would help
maintenance. You could consider using a shared database for all (most)
stored procedure access. That should allow you to use a single set of
procs for all user databases. Instead of executing the procedure in the
current database, just prefix the shared db (shareddb.dbo.procname).
David Gugick
Imceda Software
www.imceda.com|||Brian
There are no reasons to create a database for each client. I think you are
going to build a new model of the database , only you do know a business
requrements.
Visit at www.sql-server_performance.com and you will find a really good
stuff there.
"Brian" <brian@.nospam.com> wrote in message
news:%23k$J8cpuEHA.3808@.TK2MSFTNGP10.phx.gbl...
> I started work a new company recently and they provide a web based tool to
> companies. The database model is in rough shape -- when a new client
comes
> on they simply create a new database for each client. Right now they have
> roughly 400+ databases split over two database servers.
> I am suggesting they bring that # down to a couple. I think managing 400
> connections to a variety of databases might be a performance concern. I
> would also think that in terms of Stored Procs it must be using more
> resources -- instead of optimizing 1 it has to optimize the same 1, 400
> times.
> Im guessing on those above -- does anyone know the postive and negatives
in
> doing this, or know of any article discussing this topic.
> Thanks
>|||It is an administrator's nightmare. However, if the DBs for each of your
clients has data related to that specific client and should not be mixed
with other clients (which is correct) then I guess, you will have to live
with it. If the DBs contain code and metadata for your web based client
application, then consolidating is the right approach.
"Brian" <brian@.nospam.com> wrote in message
news:#k$J8cpuEHA.3808@.TK2MSFTNGP10.phx.gbl...
> I started work a new company recently and they provide a web based tool to
> companies. The database model is in rough shape -- when a new client
comes
> on they simply create a new database for each client. Right now they have
> roughly 400+ databases split over two database servers.
> I am suggesting they bring that # down to a couple. I think managing 400
> connections to a variety of databases might be a performance concern. I
> would also think that in terms of Stored Procs it must be using more
> resources -- instead of optimizing 1 it has to optimize the same 1, 400
> times.
> Im guessing on those above -- does anyone know the postive and negatives
in
> doing this, or know of any article discussing this topic.
> Thanks
>|||Have you considered using partitioned views to unify all this data in a
common DB? Using that method you may only need a single copy of much of your
server-side code.
I would have expected that the main argument for unifying the databases into
one would be based on the potential savings on development, reporting and
admin costs over the costs of those things for 100s of identical databases.
--
David Portas
SQL Server MVP
--|||There is little to no difference between the databases. A couple clients
have a few custom pieces but nothing that could not be solved in the data
model.
Aside from the admin nightmare (it exists now), is there any performance
hit. I guess this may be more is an IIS webserver question. Having to
manage 400 different connection strings.
And again the duplicate Stored Procs, and who knows what else.
"Bhanu" <SQLDBA1999@.yahoo.com> wrote in message
news:uwhvCspuEHA.2144@.tk2msftngp13.phx.gbl...
> It is an administrator's nightmare. However, if the DBs for each of your
> clients has data related to that specific client and should not be mixed
> with other clients (which is correct) then I guess, you will have to live
> with it. If the DBs contain code and metadata for your web based client
> application, then consolidating is the right approach.
>
>
> "Brian" <brian@.nospam.com> wrote in message
> news:#k$J8cpuEHA.3808@.TK2MSFTNGP10.phx.gbl...
>> I started work a new company recently and they provide a web based tool
>> to
>> companies. The database model is in rough shape -- when a new client
> comes
>> on they simply create a new database for each client. Right now they
>> have
>> roughly 400+ databases split over two database servers.
>> I am suggesting they bring that # down to a couple. I think managing 400
>> connections to a variety of databases might be a performance concern. I
>> would also think that in terms of Stored Procs it must be using more
>> resources -- instead of optimizing 1 it has to optimize the same 1, 400
>> times.
>> Im guessing on those above -- does anyone know the postive and negatives
> in
>> doing this, or know of any article discussing this topic.
>> Thanks
>>
>|||Hi Brian,
I am a dba for multiple companies in a datacenter and one of our companies
has around 400 lawfirms and everything is in one database. The main thing
that you have to think about is security. In our case each lawfirm has a role
and many tables contain a field that specifies to which law firm the row
belongs (row level security). This is basically the idea but it gets more
complex when you have multiple groups with each law firm. This is based on
the requirements and something that you have to analyze). If it was me, I
would create one database with 2 clients and test the crap out of it... The
process might be painful but you have a lot to win as a DBA (amount of work
for you and the developers, $$$, more simplified disaster recovery
process...).
--
Sasan Saidi, MSc. in CS
"Brian" wrote:
> I started work a new company recently and they provide a web based tool to
> companies. The database model is in rough shape -- when a new client comes
> on they simply create a new database for each client. Right now they have
> roughly 400+ databases split over two database servers.
> I am suggesting they bring that # down to a couple. I think managing 400
> connections to a variety of databases might be a performance concern. I
> would also think that in terms of Stored Procs it must be using more
> resources -- instead of optimizing 1 it has to optimize the same 1, 400
> times.
> Im guessing on those above -- does anyone know the postive and negatives in
> doing this, or know of any article discussing this topic.
> Thanks
>
>|||Personally I would go for the smaller the number of
databases the better.
Here are two reasons.
If you need a to make a change to the schema (i.e. insert
a new table), you will need to insert the new table into
every database table, and that goes for every schema
change and standard / generic database changes.
The second is general DB work, you will need to write a
lot of generic procedures that effect all the databases.
There however a really big downside to this which is
security. Assuming each customer db has there own users /
roles ect putting them all into one big database can be a
bit of a problem, as SQL Server as yet does not have
automatic row selections for specific users.
Here is an example.
You have three databases, each of them has
a 'PersonDetails' table. You mold them into one big table,
how do you stop the people in database 1 accessing info in
database 2.
It is possible to implement this, but requires a change to
your schema.
However my personal opinon still stands.
Peter
"Real knowledge is to know the extent of one's ignorance."
Confucius
>--Original Message--
>I started work a new company recently and they provide a
web based tool to
>companies. The database model is in rough shape -- when
a new client comes
>on they simply create a new database for each client.
Right now they have
>roughly 400+ databases split over two database servers.
>I am suggesting they bring that # down to a couple. I
think managing 400
>connections to a variety of databases might be a
performance concern. I
>would also think that in terms of Stored Procs it must be
using more
>resources -- instead of optimizing 1 it has to optimize
the same 1, 400
>times.
>Im guessing on those above -- does anyone know the
postive and negatives in
>doing this, or know of any article discussing this topic.
>Thanks
>
>.
>|||Hi Brian,
I have noticed Peter and Sasan Saidi had given their suggestions on this
issue. I wanted to post a quick note to see if you would like additional
assistance or information regarding this particular issue. We appreciate
your patience and look forward to hearing from you!
Sincerely yours,
Michael Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
---
Get Secure! - http://www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!

Multiple Databases vs a Few

I started work a new company recently and they provide a web based tool to
companies. The database model is in rough shape -- when a new client comes
on they simply create a new database for each client. Right now they have
roughly 400+ databases split over two database servers.
I am suggesting they bring that # down to a couple. I think managing 400
connections to a variety of databases might be a performance concern. I
would also think that in terms of Stored Procs it must be using more
resources -- instead of optimizing 1 it has to optimize the same 1, 400
times.
Im guessing on those above -- does anyone know the postive and negatives in
doing this, or know of any article discussing this topic.
ThanksBrian wrote:
> I started work a new company recently and they provide a web based
> tool to companies. The database model is in rough shape -- when a
> new client comes on they simply create a new database for each
> client. Right now they have roughly 400+ databases split over two
> database servers.
> I am suggesting they bring that # down to a couple. I think managing
> 400 connections to a variety of databases might be a performance
> concern. I would also think that in terms of Stored Procs it must
> be using more resources -- instead of optimizing 1 it has to optimize
> the same 1, 400 times.
> Im guessing on those above -- does anyone know the postive and
> negatives in doing this, or know of any article discussing this topic.
> Thanks
I don't necessarily think using separate databases is an architectural
problem. It does, however, lead to more involved backups and SP
management. OTOH, the databases are smaller, can be backed up more
quickly, and different databases offers a level of security that might
be more difficult to manage should all clients be combined into the same
tables in the same database. What happens when a client leaves? How
involved is the removal of data if they share tables? What happens if
one client's data is accidentally shown as being "owned" by another
client? Does that lead to potential legal concerns... You get the idea.
The architecture, it seems, may need to involve legal as well as IT.
Your comments about SP duplication, however, is a concern. Certainly, if
you could find a way to share all common procedures, it would help
maintenance. You could consider using a shared database for all (most)
stored procedure access. That should allow you to use a single set of
procs for all user databases. Instead of executing the procedure in the
current database, just prefix the shared db (shareddb.dbo.procname).
David Gugick
Imceda Software
www.imceda.com|||Brian
There are no reasons to create a database for each client. I think you are
going to build a new model of the database , only you do know a business
requrements.
Visit at www.sql-server_performance.com and you will find a really good
stuff there.
"Brian" <brian@.nospam.com> wrote in message
news:%23k$J8cpuEHA.3808@.TK2MSFTNGP10.phx.gbl...
> I started work a new company recently and they provide a web based tool to
> companies. The database model is in rough shape -- when a new client
comes
> on they simply create a new database for each client. Right now they have
> roughly 400+ databases split over two database servers.
> I am suggesting they bring that # down to a couple. I think managing 400
> connections to a variety of databases might be a performance concern. I
> would also think that in terms of Stored Procs it must be using more
> resources -- instead of optimizing 1 it has to optimize the same 1, 400
> times.
> Im guessing on those above -- does anyone know the postive and negatives
in
> doing this, or know of any article discussing this topic.
> Thanks
>|||It is an administrator's nightmare. However, if the DBs for each of your
clients has data related to that specific client and should not be mixed
with other clients (which is correct) then I guess, you will have to live
with it. If the DBs contain code and metadata for your web based client
application, then consolidating is the right approach.
"Brian" <brian@.nospam.com> wrote in message
news:#k$J8cpuEHA.3808@.TK2MSFTNGP10.phx.gbl...
> I started work a new company recently and they provide a web based tool to
> companies. The database model is in rough shape -- when a new client
comes
> on they simply create a new database for each client. Right now they have
> roughly 400+ databases split over two database servers.
> I am suggesting they bring that # down to a couple. I think managing 400
> connections to a variety of databases might be a performance concern. I
> would also think that in terms of Stored Procs it must be using more
> resources -- instead of optimizing 1 it has to optimize the same 1, 400
> times.
> Im guessing on those above -- does anyone know the postive and negatives
in
> doing this, or know of any article discussing this topic.
> Thanks
>|||Have you considered using partitioned views to unify all this data in a
common DB? Using that method you may only need a single copy of much of your
server-side code.
I would have expected that the main argument for unifying the databases into
one would be based on the potential savings on development, reporting and
admin costs over the costs of those things for 100s of identical databases.
David Portas
SQL Server MVP
--|||There is little to no difference between the databases. A couple clients
have a few custom pieces but nothing that could not be solved in the data
model.
Aside from the admin nightmare (it exists now), is there any performance
hit. I guess this may be more is an IIS webserver question. Having to
manage 400 different connection strings.
And again the duplicate Stored Procs, and who knows what else.
"Bhanu" <SQLDBA1999@.yahoo.com> wrote in message
news:uwhvCspuEHA.2144@.tk2msftngp13.phx.gbl...
> It is an administrator's nightmare. However, if the DBs for each of your
> clients has data related to that specific client and should not be mixed
> with other clients (which is correct) then I guess, you will have to live
> with it. If the DBs contain code and metadata for your web based client
> application, then consolidating is the right approach.
>
>
> "Brian" <brian@.nospam.com> wrote in message
> news:#k$J8cpuEHA.3808@.TK2MSFTNGP10.phx.gbl...
> comes
> in
>|||Hi Brian,
I am a dba for multiple companies in a datacenter and one of our companies
has around 400 lawfirms and everything is in one database. The main thing
that you have to think about is security. In our case each lawfirm has a rol
e
and many tables contain a field that specifies to which law firm the row
belongs (row level security). This is basically the idea but it gets more
complex when you have multiple groups with each law firm. This is based on
the requirements and something that you have to analyze). If it was me, I
would create one database with 2 clients and test the crap out of it... The
process might be painful but you have a lot to win as a DBA (amount of work
for you and the developers, $$$, more simplified disaster recovery
process...).
Sasan Saidi, MSc. in CS
"Brian" wrote:

> I started work a new company recently and they provide a web based tool to
> companies. The database model is in rough shape -- when a new client come
s
> on they simply create a new database for each client. Right now they have
> roughly 400+ databases split over two database servers.
> I am suggesting they bring that # down to a couple. I think managing 400
> connections to a variety of databases might be a performance concern. I
> would also think that in terms of Stored Procs it must be using more
> resources -- instead of optimizing 1 it has to optimize the same 1, 400
> times.
> Im guessing on those above -- does anyone know the postive and negatives
in
> doing this, or know of any article discussing this topic.
> Thanks
>
>|||Hi Brian,
I have noticed Peter and Sasan Saidi had given their suggestions on this
issue. I wanted to post a quick note to see if you would like additional
assistance or information regarding this particular issue. We appreciate
your patience and look forward to hearing from you!
Sincerely yours,
Michael Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
---
Get Secure! - http://www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!

Multiple Database hits vs Bulk Data parameters

I was curious to know if it the amount of data sent to the sql server mattered.I am working on a web application and I have three stored procedures that most likely will be called one after the other. Each procedure accepts at least 4 parameters. Instead if I create one stored procedure, then I will be passing at least 12 parameters. Some of the parameters could be quite bulky(at least 1000 characters).So which one is better, 1 stored procedure with 12 parameters or 3 stored procedures with 4 parameters each called one after the other.Thanks

For SQL Server, the cost of parsing parameters can always be ingonred compared with the cost of compiling a store procedure and producing a optimized execution plan for it.

From network I/O aspect, each execution of a stored procedure is considered as a 'batch' (batch in SQL means all data will be processed and returned at one time, which can greatly improve network performance). So if you use 3 stored procedures, you need 3 rounds; while 1 stored procedure need only 1 round.

So generally I suggest you use 1 stored procedure with 12 parameters.

Multiple database access problem

Hi ,

Im developing a web application which would make access to multiple distributive databases. The problem is...the database from all the third parties may have different standard.
For instance...a user wish to retrive a record from many databases, he input "Pentium 4" ....but some database may have different standard, they may have a record with name "P4" instead of "Pentium 4"...so my question is , how should i make it standard ?? thanksEither use translation tables or enforce standard values through the use of foreign keys to static lookup lists.|||Great, would appreciate if you could describe more in detail ...thanks a lot|||A translation table is a table in a central database that contains the datasource, foreignvalue, and commonvalue for all the elements that need to be combined across databases.

Lookup tables are tables within each database that limit the user's choices to a selection of consistent values.

Multiple Customers Same Database

We have a client that has a web application that is accessed by multiple
customers. They are using one database to store all data for all customers.
One potential customer is concerned about storing the data this way. They ar
e
worried that their data could be accessed by other customers.
Our client has asked us to come up with a list of pros and cons of storing
all customers data in the same database. We have brainstormed and came up
with a few. Can any of you offer your thoughts?
--
Thanks,
Dan Jurden
http://www.eps-cs.comDan,
If you have a large number of customers, then maintaining those databases
via Enterprise Manager can be challenging. You also have to deal with
upgrades, such as a schema change across all those databases, as well as the
fact that you'll have to duplicate stored procedures (most likely) across
all the dbs.
On the other hand, for a relatively small number of customers, say less than
20 or so, having them all in separate databases is much much cleaner.
Hope this helps,
Ron
--
Ron Talmage
SQL Server MVP
"Dan Jurden" <DanJurden@.discussions.microsoft.com> wrote in message
news:1FFE95EE-645E-4B01-A5FC-D351F1B92467@.microsoft.com...
> We have a client that has a web application that is accessed by multiple
> customers. They are using one database to store all data for all
> customers.
> One potential customer is concerned about storing the data this way. They
> are
> worried that their data could be accessed by other customers.
> Our client has asked us to come up with a list of pros and cons of storing
> all customers data in the same database. We have brainstormed and came up
> with a few. Can any of you offer your thoughts?
> --
> Thanks,
> Dan Jurden
> http://www.eps-cs.com

Multiple Customers Same Database

We have a client that has a web application that is accessed by multiple
customers. They are using one database to store all data for all customers.
One potential customer is concerned about storing the data this way. They are
worried that their data could be accessed by other customers.
Our client has asked us to come up with a list of pros and cons of storing
all customers data in the same database. We have brainstormed and came up
with a few. Can any of you offer your thoughts?
Thanks,
Dan Jurden
http://www.eps-cs.com
Dan,
If you have a large number of customers, then maintaining those databases
via Enterprise Manager can be challenging. You also have to deal with
upgrades, such as a schema change across all those databases, as well as the
fact that you'll have to duplicate stored procedures (most likely) across
all the dbs.
On the other hand, for a relatively small number of customers, say less than
20 or so, having them all in separate databases is much much cleaner.
Hope this helps,
Ron
Ron Talmage
SQL Server MVP
"Dan Jurden" <DanJurden@.discussions.microsoft.com> wrote in message
news:1FFE95EE-645E-4B01-A5FC-D351F1B92467@.microsoft.com...
> We have a client that has a web application that is accessed by multiple
> customers. They are using one database to store all data for all
> customers.
> One potential customer is concerned about storing the data this way. They
> are
> worried that their data could be accessed by other customers.
> Our client has asked us to come up with a list of pros and cons of storing
> all customers data in the same database. We have brainstormed and came up
> with a few. Can any of you offer your thoughts?
> --
> Thanks,
> Dan Jurden
> http://www.eps-cs.com

Multiple Customers Same Database

We have a client that has a web application that is accessed by multiple
customers. They are using one database to store all data for all customers.
One potential customer is concerned about storing the data this way. They are
worried that their data could be accessed by other customers.
Our client has asked us to come up with a list of pros and cons of storing
all customers data in the same database. We have brainstormed and came up
with a few. Can any of you offer your thoughts?
--
Thanks,
Dan Jurden
http://www.eps-cs.comDan,
If you have a large number of customers, then maintaining those databases
via Enterprise Manager can be challenging. You also have to deal with
upgrades, such as a schema change across all those databases, as well as the
fact that you'll have to duplicate stored procedures (most likely) across
all the dbs.
On the other hand, for a relatively small number of customers, say less than
20 or so, having them all in separate databases is much much cleaner.
Hope this helps,
Ron
--
Ron Talmage
SQL Server MVP
"Dan Jurden" <DanJurden@.discussions.microsoft.com> wrote in message
news:1FFE95EE-645E-4B01-A5FC-D351F1B92467@.microsoft.com...
> We have a client that has a web application that is accessed by multiple
> customers. They are using one database to store all data for all
> customers.
> One potential customer is concerned about storing the data this way. They
> are
> worried that their data could be accessed by other customers.
> Our client has asked us to come up with a list of pros and cons of storing
> all customers data in the same database. We have brainstormed and came up
> with a few. Can any of you offer your thoughts?
> --
> Thanks,
> Dan Jurden
> http://www.eps-cs.com

Multiple connections from IIS on 1433 causing problems

I have SQL2000 with 8 databases running on the LAN. In our DMZ we have
a web server [IIS5] which connects to the SQL on 1433 through the
DMZ/LAN port. Up until last Tuesday everything seemed OK with approx 10
connections form DMZ>>LAN on port 1433 whenever the site was opened.
However now I am seeing 50-60 connections even though there are only a
max of 10 users connected.
As a test I closed the website to the WAN [0 connections] and opened
one occurrence of the website . It immediately, created 2 IIS
connections and 10 SQL connections. After 20-30 seconds the SQL dropped
to 2 connections until I clicked an internal link, & then it rose back
to 10 again.
Does this make sense, I dont know what the developers may have done to
trigger this and not sure where to go next. Connection pooling is
enabled & we use DSNs to make the IIS>>>SQL connections.
Thanx for your time
G> Does this make sense, I dont know what the developers may have done to
> trigger this and not sure where to go next. Connection pooling is
> enabled & we use DSNs to make the IIS>>>SQL connections.
Basically, the high-water mark should reflect the number of concurrent open
connections needed by the application. Keep in mind that when concurrent
queries are executed, each requires a separate connection and ADO will
dynamically create additional connection objects as needed. You might try a
Profiler Trace including Batch Starting, RPC Starting, Batch Completed and
RPC Completed events to help identify the cause.
Hope this helps.
Dan Guzman
SQL Server MVP
"gstar" <gary.brett@.gmail.com> wrote in message
news:1168856615.584379.217420@.l53g2000cwa.googlegroups.com...
>I have SQL2000 with 8 databases running on the LAN. In our DMZ we have
> a web server [IIS5] which connects to the SQL on 1433 through the
> DMZ/LAN port. Up until last Tuesday everything seemed OK with approx 10
> connections form DMZ>>LAN on port 1433 whenever the site was opened.
> However now I am seeing 50-60 connections even though there are only a
> max of 10 users connected.
> As a test I closed the website to the WAN [0 connections] and opened
> one occurrence of the website . It immediately, created 2 IIS
> connections and 10 SQL connections. After 20-30 seconds the SQL dropped
> to 2 connections until I clicked an internal link, & then it rose back
> to 10 again.
> Does this make sense, I dont know what the developers may have done to
> trigger this and not sure where to go next. Connection pooling is
> enabled & we use DSNs to make the IIS>>>SQL connections.
> Thanx for your time
> G
>|||I have see this problem before. If you are running IIS, I am assuming
asp or aspx (.net). If you have more connections than users, it is
probably that the application is not closing connections properly. In
"classic ASP" you had a command to open the connection - often at the
top of the web page, ran your query and then closed it at the bottom of
the page as the code was interpreted. Maybe this will help give the
developers some ideas. Same sort of concept can happen with .NET.
KR
Dan Guzman wrote:[vbcol=seagreen]
> Basically, the high-water mark should reflect the number of concurrent ope
n
> connections needed by the application. Keep in mind that when concurrent
> queries are executed, each requires a separate connection and ADO will
> dynamically create additional connection objects as needed. You might try
a
> Profiler Trace including Batch Starting, RPC Starting, Batch Completed and
> RPC Completed events to help identify the cause.
>
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "gstar" <gary.brett@.gmail.com> wrote in message
> news:1168856615.584379.217420@.l53g2000cwa.googlegroups.com...

Multiple connections from IIS on 1433 causing problems

I have SQL2000 with 8 databases running on the LAN. In our DMZ we have
a web server [IIS5] which connects to the SQL on 1433 through the
DMZ/LAN port. Up until last Tuesday everything seemed OK with approx 10
connections form DMZ>>LAN on port 1433 whenever the site was opened.
However now I am seeing 50-60 connections even though there are only a
max of 10 users connected.
As a test I closed the website to the WAN [0 connections] and opened
one occurrence of the website . It immediately, created 2 IIS
connections and 10 SQL connections. After 20-30 seconds the SQL dropped
to 2 connections until I clicked an internal link, & then it rose back
to 10 again.
Does this make sense, I dont know what the developers may have done to
trigger this and not sure where to go next. Connection pooling is
enabled & we use DSNs to make the IIS>>SQL connections.
Thanx for your time
G> Does this make sense, I dont know what the developers may have done to
> trigger this and not sure where to go next. Connection pooling is
> enabled & we use DSNs to make the IIS>>SQL connections.
Basically, the high-water mark should reflect the number of concurrent open
connections needed by the application. Keep in mind that when concurrent
queries are executed, each requires a separate connection and ADO will
dynamically create additional connection objects as needed. You might try a
Profiler Trace including Batch Starting, RPC Starting, Batch Completed and
RPC Completed events to help identify the cause.
Hope this helps.
Dan Guzman
SQL Server MVP
"gstar" <gary.brett@.gmail.com> wrote in message
news:1168856615.584379.217420@.l53g2000cwa.googlegroups.com...
>I have SQL2000 with 8 databases running on the LAN. In our DMZ we have
> a web server [IIS5] which connects to the SQL on 1433 through the
> DMZ/LAN port. Up until last Tuesday everything seemed OK with approx 10
> connections form DMZ>>LAN on port 1433 whenever the site was opened.
> However now I am seeing 50-60 connections even though there are only a
> max of 10 users connected.
> As a test I closed the website to the WAN [0 connections] and opened
> one occurrence of the website . It immediately, created 2 IIS
> connections and 10 SQL connections. After 20-30 seconds the SQL dropped
> to 2 connections until I clicked an internal link, & then it rose back
> to 10 again.
> Does this make sense, I dont know what the developers may have done to
> trigger this and not sure where to go next. Connection pooling is
> enabled & we use DSNs to make the IIS>>SQL connections.
> Thanx for your time
> G
>|||I have see this problem before. If you are running IIS, I am assuming
asp or aspx (.net). If you have more connections than users, it is
probably that the application is not closing connections properly. In
"classic ASP" you had a command to open the connection - often at the
top of the web page, ran your query and then closed it at the bottom of
the page as the code was interpreted. Maybe this will help give the
developers some ideas. Same sort of concept can happen with .NET.
KR
Dan Guzman wrote:
> > Does this make sense, I dont know what the developers may have done to
> > trigger this and not sure where to go next. Connection pooling is
> > enabled & we use DSNs to make the IIS>>SQL connections.
> Basically, the high-water mark should reflect the number of concurrent open
> connections needed by the application. Keep in mind that when concurrent
> queries are executed, each requires a separate connection and ADO will
> dynamically create additional connection objects as needed. You might try a
> Profiler Trace including Batch Starting, RPC Starting, Batch Completed and
> RPC Completed events to help identify the cause.
>
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "gstar" <gary.brett@.gmail.com> wrote in message
> news:1168856615.584379.217420@.l53g2000cwa.googlegroups.com...
> >I have SQL2000 with 8 databases running on the LAN. In our DMZ we have
> > a web server [IIS5] which connects to the SQL on 1433 through the
> > DMZ/LAN port. Up until last Tuesday everything seemed OK with approx 10
> > connections form DMZ>>LAN on port 1433 whenever the site was opened.
> > However now I am seeing 50-60 connections even though there are only a
> > max of 10 users connected.
> >
> > As a test I closed the website to the WAN [0 connections] and opened
> > one occurrence of the website . It immediately, created 2 IIS
> > connections and 10 SQL connections. After 20-30 seconds the SQL dropped
> > to 2 connections until I clicked an internal link, & then it rose back
> > to 10 again.
> >
> > Does this make sense, I dont know what the developers may have done to
> > trigger this and not sure where to go next. Connection pooling is
> > enabled & we use DSNs to make the IIS>>SQL connections.
> >
> > Thanx for your time
> >
> > G
> >

Multiple Client on the same ReportServer

Hi !

Once again i have a question . We have a Web application and lately we have install ReportBuilder to allow some of our Clients to create their own reports. I was wondering how to "hide" reports made by a Client from another client ? For exemple if a Client 'A' create a report and save it on his folder. When the client 'B' open reportBuilder and select the option OPEN, currently the Client 'B' can see the folder of the Client 'A'. So the Client 'B' could modify a report that belong to another client.

I was looking in the Report Manager but i couldn't find how to 'hide' a folder from user using the security option. Maybe we haven't configuer ReportServer propely. How can we solve this problem ? Is there a good website that explain how to do this ?I've forgot to ask something else. Currently we have made over 600 reports. All our Clients can use thoses reports but we don't want to allow them to modify them. Is it possible to hide a project from all our Client ?|||Anyone ? I really need to find a solution because we can let a Client have access to reports of another client.

Thanks ! Sorry about my bad English ^_^

multiple blob

A table has a text field which provides content on a web page.
If the web content was to be regionalised, what would be the pros/cons of
having a text field for each region in the same record?
Thanks Soc.The main downside IMHO would be a total loss of scalability. Why not just us
e
the ntext datatype? That way you can just keep all in one column. Look up us
e
of unicode data types in Books Online.
ML|||How would you keep them all in one column? The ntext datatype only allows
unicode characters, not special regionlization (unless I am about to learn
something :)
----
Louis Davidson - http://spaces.msn.com/members/drsql/
SQL Server MVP
"Arguments are to be avoided: they are always vulgar and often convincing."
(Oscar Wilde)
"ML" <ML@.discussions.microsoft.com> wrote in message
news:73A4CA11-1D30-4C0E-92D1-A72187B07E62@.microsoft.com...
> The main downside IMHO would be a total loss of scalability. Why not just
> use
> the ntext datatype? That way you can just keep all in one column. Look up
> use
> of unicode data types in Books Online.
>
> ML|||That's not exactly what I meant, but hey, why not?
ItemID : LanguageID : Text
Or did you mean all of them in one row? Now, that even I can't imagine. :)
No, wait... I can! If all they're inside an XML. But that's just silly, righ
t?
E.g. ItemID : XML
Item Text
BookTitle <values>
<value language="english">A summer night's
dream</value>
<value language="Deutsch">Ein sommer Nachts
Traum</value>
</values>
ML|||I didn't figure it was really what you meant. But you are right, you could
use XML, depending on the actual needs.
----
Louis Davidson - http://spaces.msn.com/members/drsql/
SQL Server MVP
"Arguments are to be avoided: they are always vulgar and often convincing."
(Oscar Wilde)
"ML" <ML@.discussions.microsoft.com> wrote in message
news:AE81E10E-DBEF-4FD7-B5E6-38C9AA2CF27A@.microsoft.com...
> That's not exactly what I meant, but hey, why not?
> ItemID : LanguageID : Text
> Or did you mean all of them in one row? Now, that even I can't imagine. :)
> No, wait... I can! If all they're inside an XML. But that's just silly,
> right?
> E.g. ItemID : XML
> Item Text
> BookTitle <values>
> <value language="english">A summer night's
> dream</value>
> <value language="Deutsch">Ein sommer Nachts
> Traum</value>
> </values>
>
> ML|||On Fri, 9 Sep 2005 16:12:16 +0100, soc wrote:

>A table has a text field which provides content on a web page.
>If the web content was to be regionalised, what would be the pros/cons of
>having a text field for each region in the same record?
>Thanks Soc.
>
Hi Soc,
Pros: none that I can think of.
Cons: not normalised, not scalable.
Better to have an extra table, with foreign key to the main table,
language code plus this foreign key as the primary key and the
translated contents as the third column.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||Thanks all.
I agree with the separate table option...
"Hugo Kornelis" <hugo@.pe_NO_rFact.in_SPAM_fo> wrote in message
news:4804i1pd5an6r5jl1m42rttos800j7sapt@.
4ax.com...
> On Fri, 9 Sep 2005 16:12:16 +0100, soc wrote:
>
> Hi Soc,
> Pros: none that I can think of.
> Cons: not normalised, not scalable.
> Better to have an extra table, with foreign key to the main table,
> language code plus this foreign key as the primary key and the
> translated contents as the third column.
> Best, Hugo
> --
> (Remove _NO_ and _SPAM_ to get my e-mail address)
>