Which layer do you build the connection string?

[H]

This is a question that has haunted me for quite some time.

if you build a 4 tier database application where the 4th tier is the
database server (MS SQL 2000), where do you build the connection string?

The obvious answer is to hard code it into the middle layer and use a config
file.

The problem is the database application needs to be distributed to
purchasing clients. Therefore, you do not know, at development, what the SQL
Server is going to be called or what name they want to give the database.

My solution has been to ask for the server and database name at installation
of the client (gui) part. Strictly speaking, the client layer should not
have to know this.

Any one got the correct approach ?

I have looked through several books, but the text refers to in-house db
apps.

Regards H

[Peter Rilling]

Actually, I think that the client is the correct place to put this
information, in my opinion. The client should read the connection string
from the app.config (or some other storage area) and pass that information
to the objects that it controls. For instance, the client might initialize
some object that ends up doing most of the database work. In that case,
maybe just pass the connection string into the constructor.

My philosophy is to have all configurable parameters as close to the client
as possible and that makes the others tiers more flexible in that all you do
is pass the setting and the tiers do not have to worry about a specific
location for those settings.

"H" <[e-mail]> wrote in message
news:cp**********@titan.btinternet.com...

This is a question that has haunted me for quite some time.

if you build a 4 tier database application where the 4th tier is the
database server (MS SQL 2000), where do you build the connection string?

The obvious answer is to hard code it into the middle layer and use a config file.

The problem is the database application needs to be distributed to
purchasing clients. Therefore, you do not know, at development, what the SQL Server is going to be called or what name they want to give the database.

My solution has been to ask for the server and database name at installation of the client (gui) part. Strictly speaking, the client layer should not
have to know this.

Any one got the correct approach ?

I have looked through several books, but the text refers to in-house db
apps.

Regards H

[H]

Peter

that's been roughly my philosophy. However, does it still work if the Users
(for reasons known only to them) would change the server name.

If you have a few workstations on a LAN, it's not a problem to change the
settings. What if its many workstations on a WAN?

Is it worth the overhead of re-installation for this sort of change?

Regards

H
"Peter Rilling" <pe***@nospam.rilling.net> wrote in message
news:ux**************@TK2MSFTNGP14.phx.gbl...

Actually, I think that the client is the correct place to put this
information, in my opinion. The client should read the connection string
from the app.config (or some other storage area) and pass that information
to the objects that it controls. For instance, the client might
initialize
some object that ends up doing most of the database work. In that case,
maybe just pass the connection string into the constructor.

My philosophy is to have all configurable parameters as close to the
client
as possible and that makes the others tiers more flexible in that all you
do
is pass the setting and the tiers do not have to worry about a specific
location for those settings.

"H" <[e-mail]> wrote in message
news:cp**********@titan.btinternet.com...

This is a question that has haunted me for quite some time.

if you build a 4 tier database application where the 4th tier is the
database server (MS SQL 2000), where do you build the connection string?

The obvious answer is to hard code it into the middle layer and use a

config

file.

The problem is the database application needs to be distributed to
purchasing clients. Therefore, you do not know, at development, what the

SQL

Server is going to be called or what name they want to give the database.

My solution has been to ask for the server and database name at

installation

of the client (gui) part. Strictly speaking, the client layer should not
have to know this.

Any one got the correct approach ?

I have looked through several books, but the text refers to in-house db
apps.

Regards H

[Nick Malik]

not so hard to fix... have the installer start a small config utility (you
may already have this). The config utility will check your web site (web
service) for a list of the server names that are valid. You can even take
the user's login name and pass it to a web service, and thus get the one
name they are supposed to use by looking it up in a database at your end.
The configurator passes the settings to the local machine's config file. If
you ask the user at all, you present him or her with a list of valid values
and you don't let them enter an invalid one.

This gives you some control over configuration.
The only thing that you hardcode: the URL of your web service.

--- Nick

"H" <[e-mail]> wrote in message
news:cp**********@titan.btinternet.com...

Peter

that's been roughly my philosophy. However, does it still work if the Users (for reasons known only to them) would change the server name.

If you have a few workstations on a LAN, it's not a problem to change the
settings. What if its many workstations on a WAN?

Is it worth the overhead of re-installation for this sort of change?

Regards

H
"Peter Rilling" <pe***@nospam.rilling.net> wrote in message
news:ux**************@TK2MSFTNGP14.phx.gbl...

Actually, I think that the client is the correct place to put this
information, in my opinion. The client should read the connection string from the app.config (or some other storage area) and pass that information to the objects that it controls. For instance, the client might
initialize
some object that ends up doing most of the database work. In that case,
maybe just pass the connection string into the constructor.

My philosophy is to have all configurable parameters as close to the
client
as possible and that makes the others tiers more flexible in that all you do
is pass the setting and the tiers do not have to worry about a specific
location for those settings.

"H" <[e-mail]> wrote in message
news:cp**********@titan.btinternet.com...

This is a question that has haunted me for quite some time.

if you build a 4 tier database application where the 4th tier is the
database server (MS SQL 2000), where do you build the connection string?
The obvious answer is to hard code it into the middle layer and use a

config

file.

The problem is the database application needs to be distributed to
purchasing clients. Therefore, you do not know, at development, what the

SQL

Server is going to be called or what name they want to give the

database.
My solution has been to ask for the server and database name at

installation

of the client (gui) part. Strictly speaking, the client layer should not have to know this.

Any one got the correct approach ?

I have looked through several books, but the text refers to in-house db
apps.

Regards H

[H]

I know that I am splitting hairs here, but, the client still needs to have a
value or a list of values that represents the valid server names to use.
Also, your assuming that the name of the web service remains unchanged.

However, with this scenario why not have the web service build the
connection string? Esp. if the Web Service and SQL Server are on the same
box.

H

"Nick Malik" <ni*******@hotmail.nospam.com> wrote in message
news:wu_td.539818$D%.465092@attbi_s51...

not so hard to fix... have the installer start a small config utility (you
may already have this). The config utility will check your web site (web
service) for a list of the server names that are valid. You can even take
the user's login name and pass it to a web service, and thus get the one
name they are supposed to use by looking it up in a database at your end.
The configurator passes the settings to the local machine's config file.
If
you ask the user at all, you present him or her with a list of valid
values
and you don't let them enter an invalid one.

This gives you some control over configuration.
The only thing that you hardcode: the URL of your web service.

--- Nick

"H" <[e-mail]> wrote in message
news:cp**********@titan.btinternet.com...

Peter

that's been roughly my philosophy. However, does it still work if the

Users

(for reasons known only to them) would change the server name.

If you have a few workstations on a LAN, it's not a problem to change the
settings. What if its many workstations on a WAN?

Is it worth the overhead of re-installation for this sort of change?

Regards

H
"Peter Rilling" <pe***@nospam.rilling.net> wrote in message
news:ux**************@TK2MSFTNGP14.phx.gbl...

> Actually, I think that the client is the correct place to put this
> information, in my opinion. The client should read the connection string > from the app.config (or some other storage area) and pass that information > to the objects that it controls. For instance, the client might
> initialize
> some object that ends up doing most of the database work. In that
> case,
> maybe just pass the connection string into the constructor.
>
> My philosophy is to have all configurable parameters as close to the
> client
> as possible and that makes the others tiers more flexible in that all you > do
> is pass the setting and the tiers do not have to worry about a specific
> location for those settings.
>
> "H" <[e-mail]> wrote in message
> news:cp**********@titan.btinternet.com...
>> This is a question that has haunted me for quite some time.
>>
>> if you build a 4 tier database application where the 4th tier is the
>> database server (MS SQL 2000), where do you build the connection string? >>
>> The obvious answer is to hard code it into the middle layer and use a
> config
>> file.
>>
>> The problem is the database application needs to be distributed to
>> purchasing clients. Therefore, you do not know, at development, what the > SQL
>> Server is going to be called or what name they want to give the database. >>
>> My solution has been to ask for the server and database name at
> installation
>> of the client (gui) part. Strictly speaking, the client layer should not >> have to know this.
>>
>> Any one got the correct approach ?
>>
>> I have looked through several books, but the text refers to in-house
>> db
>> apps.
>>
>> Regards H
>>
>>
>
>

[Nick Malik]

The client gets the list of valid server names from the web service.

Yes, I am assuming that the name of the web service remains unchanged.
That's the beauty of DNS. Give it a name in DNS and you don't ever have to
worry about where the server lives.

It is fine to have the web service build the connection string, as long as
the user doesn't have to choose more than one server name. If you can go
from the user id to the correct server name, without end-user input, all the
better.

--- Nick

"H" <[e-mail]> wrote in message
news:cp**********@sparta.btinternet.com...

I know that I am splitting hairs here, but, the client still needs to have a value or a list of values that represents the valid server names to use.
Also, your assuming that the name of the web service remains unchanged.

However, with this scenario why not have the web service build the
connection string? Esp. if the Web Service and SQL Server are on the same
box.

H

"Nick Malik" <ni*******@hotmail.nospam.com> wrote in message
news:wu_td.539818$D%.465092@attbi_s51...

not so hard to fix... have the installer start a small config utility (you may already have this). The config utility will check your web site (web service) for a list of the server names that are valid. You can even take the user's login name and pass it to a web service, and thus get the one
name they are supposed to use by looking it up in a database at your end. The configurator passes the settings to the local machine's config file.
If
you ask the user at all, you present him or her with a list of valid
values
and you don't let them enter an invalid one.

This gives you some control over configuration.
The only thing that you hardcode: the URL of your web service.

--- Nick

"H" <[e-mail]> wrote in message
news:cp**********@titan.btinternet.com...

Peter

that's been roughly my philosophy. However, does it still work if the

Users

(for reasons known only to them) would change the server name.

If you have a few workstations on a LAN, it's not a problem to change the settings. What if its many workstations on a WAN?

Is it worth the overhead of re-installation for this sort of change?

Regards

H
"Peter Rilling" <pe***@nospam.rilling.net> wrote in message
news:ux**************@TK2MSFTNGP14.phx.gbl...
> Actually, I think that the client is the correct place to put this
> information, in my opinion. The client should read the connection

string

> from the app.config (or some other storage area) and pass that

information

> to the objects that it controls. For instance, the client might
> initialize
> some object that ends up doing most of the database work. In that
> case,
> maybe just pass the connection string into the constructor.
>
> My philosophy is to have all configurable parameters as close to the
> client
> as possible and that makes the others tiers more flexible in that all

you

> do
> is pass the setting and the tiers do not have to worry about a specific > location for those settings.
>
> "H" <[e-mail]> wrote in message
> news:cp**********@titan.btinternet.com...
>> This is a question that has haunted me for quite some time.
>>
>> if you build a 4 tier database application where the 4th tier is the
>> database server (MS SQL 2000), where do you build the connection

string?

>>
>> The obvious answer is to hard code it into the middle layer and use a > config
>> file.
>>
>> The problem is the database application needs to be distributed to
>> purchasing clients. Therefore, you do not know, at development, what

the

> SQL
>> Server is going to be called or what name they want to give the

database.

>>
>> My solution has been to ask for the server and database name at
> installation
>> of the client (gui) part. Strictly speaking, the client layer should

not

>> have to know this.
>>
>> Any one got the correct approach ?
>>
>> I have looked through several books, but the text refers to in-house
>> db
>> apps.
>>
>> Regards H
>>
>>
>
>

[Andrew McNerlin]

The Configuration Management Application Block is probably worth a look
also.

http://www.microsoft.com/downloads/d...5cb1c53-8ca7-4
a92-85e3-e4795bd27feb&displaylang=en

Andrew McNerlin
Internet Solutions (Ireland)
http://www.isoli.co.uk
-----Original Message-----
From: Nick Malik [mailto:ni*******@hotmail.nospam.com]
Posted At: 10 December 2004 08:38
Posted To: microsoft.public.dotnet.general
Conversation: Which layer do you build the connection string?
Subject: Re: Which layer do you build the connection string?

The client gets the list of valid server names from the web service.

Yes, I am assuming that the name of the web service remains unchanged.
That's the beauty of DNS. Give it a name in DNS and you don't ever have
to
worry about where the server lives.

It is fine to have the web service build the connection string, as long
as
the user doesn't have to choose more than one server name. If you can
go
from the user id to the correct server name, without end-user input, all
the
better.

--- Nick

"H" <[e-mail]> wrote in message
news:cp**********@sparta.btinternet.com...

I know that I am splitting hairs here, but, the client still needs to have
a value or a list of values that represents the valid server names to use. Also, your assuming that the name of the web service remains unchanged.
However, with this scenario why not have the web service build the
connection string? Esp. if the Web Service and SQL Server are on the same box.

H

"Nick Malik" <ni*******@hotmail.nospam.com> wrote in message
news:wu_td.539818$D%.465092@attbi_s51...

not so hard to fix... have the installer start a small config utility
(you may already have this). The config utility will check your web site (web service) for a list of the server names that are valid. You can even
take the user's login name and pass it to a web service, and thus get the one name they are supposed to use by looking it up in a database at your end. The configurator passes the settings to the local machine's config file. If
you ask the user at all, you present him or her with a list of valid
values
and you don't let them enter an invalid one.

This gives you some control over configuration.
The only thing that you hardcode: the URL of your web service.

--- Nick

"H" <[e-mail]> wrote in message
news:cp**********@titan.btinternet.com...

Peter

that's been roughly my philosophy. However, does it still work if the

Users

(for reasons known only to them) would change the server name.

If you have a few workstations on a LAN, it's not a problem to

change
the settings. What if its many workstations on a WAN?

Is it worth the overhead of re-installation for this sort of change?
Regards

H
"Peter Rilling" <pe***@nospam.rilling.net> wrote in message
news:ux**************@TK2MSFTNGP14.phx.gbl...
> Actually, I think that the client is the correct place to put this > information, in my opinion. The client should read the connection string

> from the app.config (or some other storage area) and pass that

information

> to the objects that it controls. For instance, the client might
> initialize
> some object that ends up doing most of the database work. In

that > case,
> maybe just pass the connection string into the constructor.
>
> My philosophy is to have all configurable parameters as close to the > client
> as possible and that makes the others tiers more flexible in that all you

> do
> is pass the setting and the tiers do not have to worry about a

specific > location for those settings.
>
> "H" <[e-mail]> wrote in message
> news:cp**********@titan.btinternet.com...
>> This is a question that has haunted me for quite some time.
>>
>> if you build a 4 tier database application where the 4th tier is the >> database server (MS SQL 2000), where do you build the connection

string?

>>
>> The obvious answer is to hard code it into the middle layer and use
a > config
>> file.
>>
>> The problem is the database application needs to be distributed to >> purchasing clients. Therefore, you do not know, at development, what the

> SQL
>> Server is going to be called or what name they want to give the

database.

>>
>> My solution has been to ask for the server and database name at
> installation
>> of the client (gui) part. Strictly speaking, the client layer

should not

>> have to know this.
>>
>> Any one got the correct approach ?
>>
>> I have looked through several books, but the text refers to

in-house >> db
>> apps.
>>
>> Regards H
>>
>>
>
>