User Selectable Databases

[Darryll D. Petrancuri]

Greetings:

I'm looking for ideas (other than modifying all method calls) for persisting
(on a per user basis) information on the ConnectionString for data layer
components in an MTS package.

The problem is that the user of my application needs to be able to select
which database they want to run the application against. This list cannot be
maintained or configured apriori (before hand). Don't ask why, I'm not
prepared to debate the reasons right now. So, here I am with a situation
where I can't rely on the data layer components knowing about the possible
databases before hand. There is no finite, pre-determined list. So, let's
say that I let the user select the database they want to run against in the
presentation layer. I don't want to pass this information in every method
call (or even factory methods) on business layer objects. I really only want
to pass this information to the business layer once, that will in turn pass
it to the data layer once. Then I want the data layer to save this
information (I'll use MTS' ability to to get the original caller's name and
security ID as a means by which to distinguish the user for whom the
information is for). The question is, where would you or how would you save
this "per user" information that needs to persist for as long as the
presentation layer for a specific user is running? I'm not adverse to having
a global Application object that is an MTS component in the business
services layer that is creatable by the presentation layer at start up with
methods to establish the beginning and end of the need by the presentation
layer to communicate per se (albeit indirectly) with the "database".

Can you offer some suggestions, ideas, comments or criticisms?

Thank you.

Darryll

[Steve Berzins]

Maybe a separate table to just hold this for users and use the users
identity as the criteria to update and select the info from the table??
Could use Shared Property Manager too, but probably not the best idea, if
server processes were to be shut down I think this info would be lost, and
your app would also have to worry about how to recover from this, not a
clean solution IMHO.

From what you said you know when your app is starting and quitting and could
call methods from these events, so this is where you could add your generic
component to create a temp record on start, and destroy it on exit...and all
your method calls maybe would call a third method on it that gives your MTS
components the info they need during your apps execution, sounds workable to
me...

Steve

"Darryll D. Petrancuri" <principal@dynamicpro.com> wrote in message
news:3acea440$1@news.devx.com...
> Greetings:
>
> I'm looking for ideas (other than modifying all method calls) for
persisting
> (on a per user basis) information on the ConnectionString for data layer
> components in an MTS package.
>
> The problem is that the user of my application needs to be able to select
> which database they want to run the application against. This list cannot
be
> maintained or configured apriori (before hand). Don't ask why, I'm not
> prepared to debate the reasons right now. So, here I am with a situation
> where I can't rely on the data layer components knowing about the possible
> databases before hand. There is no finite, pre-determined list. So, let's
> say that I let the user select the database they want to run against in
the
> presentation layer. I don't want to pass this information in every method
> call (or even factory methods) on business layer objects. I really only
want
> to pass this information to the business layer once, that will in turn
pass
> it to the data layer once. Then I want the data layer to save this
> information (I'll use MTS' ability to to get the original caller's name
and
> security ID as a means by which to distinguish the user for whom the
> information is for). The question is, where would you or how would you
save
> this "per user" information that needs to persist for as long as the
> presentation layer for a specific user is running? I'm not adverse to
having
> a global Application object that is an MTS component in the business
> services layer that is creatable by the presentation layer at start up
with
> methods to establish the beginning and end of the need by the presentation
> layer to communicate per se (albeit indirectly) with the "database".
>
> Can you offer some suggestions, ideas, comments or criticisms?
>
> Thank you.
>
> Darryll
>
>

[Darryll D. Petrancuri]

Steve:

Why would I want to introduce a database into the problem? Remember,
identifying the database to the data services layer IS the problem.

Anyone else?

Darryll

Steve Berzins <steveberzins@NOSPAMhotmail.com> wrote in message
news:3ad0d252@news.devx.com...
> Maybe a separate table to just hold this for users and use the users
> identity as the criteria to update and select the info from the table??
> Could use Shared Property Manager too, but probably not the best idea, if
> server processes were to be shut down I think this info would be lost, and
> your app would also have to worry about how to recover from this, not a
> clean solution IMHO.
>
> From what you said you know when your app is starting and quitting and
could
> call methods from these events, so this is where you could add your
generic
> component to create a temp record on start, and destroy it on exit...and
all
> your method calls maybe would call a third method on it that gives your
MTS
> components the info they need during your apps execution, sounds workable
to
> me...
>
> Steve
>
> "Darryll D. Petrancuri" <principal@dynamicpro.com> wrote in message
> news:3acea440$1@news.devx.com...
> > Greetings:
> >
> > I'm looking for ideas (other than modifying all method calls) for
> persisting
> > (on a per user basis) information on the ConnectionString for data layer
> > components in an MTS package.
> >
> > The problem is that the user of my application needs to be able to
select
> > which database they want to run the application against. This list
cannot
> be
> > maintained or configured apriori (before hand). Don't ask why, I'm not
> > prepared to debate the reasons right now. So, here I am with a situation
> > where I can't rely on the data layer components knowing about the
possible
> > databases before hand. There is no finite, pre-determined list. So,
let's
> > say that I let the user select the database they want to run against in
> the
> > presentation layer. I don't want to pass this information in every
method
> > call (or even factory methods) on business layer objects. I really only
> want
> > to pass this information to the business layer once, that will in turn
> pass
> > it to the data layer once. Then I want the data layer to save this
> > information (I'll use MTS' ability to to get the original caller's name
> and
> > security ID as a means by which to distinguish the user for whom the
> > information is for). The question is, where would you or how would you
> save
> > this "per user" information that needs to persist for as long as the
> > presentation layer for a specific user is running? I'm not adverse to
> having
> > a global Application object that is an MTS component in the business
> > services layer that is creatable by the presentation layer at start up
> with
> > methods to establish the beginning and end of the need by the
presentation
> > layer to communicate per se (albeit indirectly) with the "database".
> >
> > Can you offer some suggestions, ideas, comments or criticisms?
> >
> > Thank you.
> >
> > Darryll
> >
> >
>
>

[dsemen]

Hey there,

if you do not want to change function interface you have to maintain some
state information.

So, when user logs in you ask for database. After that you create some state
information in Db or in the MTS structures. Then any time user calls something
you need to build connection string. You look it up in the state structure
and pick up needed database.
This is not ideal solution because you have to deal with "lost" connections
and so on. You can add expire date/time to the connection/state.

Another way to do it:
You should create some program to install it on client computer. Any time
when MTS receives the call from the computer it "asks" the special program
on the client to tell the current database. This is more reliable method
but:
1. It increases network traffic
2. You should maintain database with user - computer relationship.
3. You will have to write quite complex Socket aware program to install it
on client.

"Darryll D. Petrancuri" <principal@dynamicpro.com> wrote:
>Greetings:
>
>I'm looking for ideas (other than modifying all method calls) for persisting
>(on a per user basis) information on the ConnectionString for data layer
>components in an MTS package.
>
>The problem is that the user of my application needs to be able to select
>which database they want to run the application against. This list cannot
be
>maintained or configured apriori (before hand). Don't ask why, I'm not
>prepared to debate the reasons right now. So, here I am with a situation
>where I can't rely on the data layer components knowing about the possible
>databases before hand. There is no finite, pre-determined list. So, let's
>say that I let the user select the database they want to run against in
the
>presentation layer. I don't want to pass this information in every method
>call (or even factory methods) on business layer objects. I really only
want
>to pass this information to the business layer once, that will in turn pass
>it to the data layer once. Then I want the data layer to save this
>information (I'll use MTS' ability to to get the original caller's name
and
>security ID as a means by which to distinguish the user for whom the
>information is for). The question is, where would you or how would you save
>this "per user" information that needs to persist for as long as the
>presentation layer for a specific user is running? I'm not adverse to having
>a global Application object that is an MTS component in the business
>services layer that is creatable by the presentation layer at start up with
>methods to establish the beginning and end of the need by the presentation
>layer to communicate per se (albeit indirectly) with the "database".
>
>Can you offer some suggestions, ideas, comments or criticisms?
>
>Thank you.
>
>Darryll
>
>

[Steve Berzins]

Why does it have to be the same database?

This one would just be used just at app startup to supply the list of
available 'real' databases.
And a table to hold this 'state' for you on a per user basis.
Even if you don't have the first part, why wouldn't a database just used to
store this state not work. It would be simple and the client doesn't have to
know anything about it.

in a separate database:
have a table with columns:
CALLER_NAME
CONNECTION_STRING

build a little helper Component

'called at app startup
SetConnectionInfo(CallerName, ConnectionString)
'called at app terminate
ClearConnectionInfo(CallerName)
'called by data services to get the users connection string when needed.
GetConnectionInfo(CallerName)

Maybe a little info as to WHY instead of 'Don't ask why, I'm not prepared to
debate the reasons right now.' may help shed something useful on the
problem.

If you need to hold this 'state' between calls in MTS objects, you need
something to hold onto it for you, and in the client server world of windows
apps this 'usually' means database or something that works similar to a
database anyway...

"Darryll D. Petrancuri" <principal@dynamicpro.com> wrote in message
news:3ad12a9e$1@news.devx.com...
> Steve:
>
> Why would I want to introduce a database into the problem? Remember,
> identifying the database to the data services layer IS the problem.
>
> Anyone else?
>
> Darryll
>
> Steve Berzins <steveberzins@NOSPAMhotmail.com> wrote in message
> news:3ad0d252@news.devx.com...
> > Maybe a separate table to just hold this for users and use the users
> > identity as the criteria to update and select the info from the table??
> > Could use Shared Property Manager too, but probably not the best idea,
if
> > server processes were to be shut down I think this info would be lost,
and
> > your app would also have to worry about how to recover from this, not a
> > clean solution IMHO.
> >
> > From what you said you know when your app is starting and quitting and
> could
> > call methods from these events, so this is where you could add your
> generic
> > component to create a temp record on start, and destroy it on exit...and
> all
> > your method calls maybe would call a third method on it that gives your
> MTS
> > components the info they need during your apps execution, sounds
workable
> to
> > me...
> >
> > Steve
> >
> > "Darryll D. Petrancuri" <principal@dynamicpro.com> wrote in message
> > news:3acea440$1@news.devx.com...
> > > Greetings:
> > >
> > > I'm looking for ideas (other than modifying all method calls) for
> > persisting
> > > (on a per user basis) information on the ConnectionString for data
layer
> > > components in an MTS package.
> > >
> > > The problem is that the user of my application needs to be able to
> select
> > > which database they want to run the application against. This list
> cannot
> > be
> > > maintained or configured apriori (before hand). Don't ask why, I'm not
> > > prepared to debate the reasons right now. So, here I am with a
situation
> > > where I can't rely on the data layer components knowing about the
> possible
> > > databases before hand. There is no finite, pre-determined list. So,
> let's
> > > say that I let the user select the database they want to run against
in
> > the
> > > presentation layer. I don't want to pass this information in every
> method
> > > call (or even factory methods) on business layer objects. I really
only
> > want
> > > to pass this information to the business layer once, that will in turn
> > pass
> > > it to the data layer once. Then I want the data layer to save this
> > > information (I'll use MTS' ability to to get the original caller's
name
> > and
> > > security ID as a means by which to distinguish the user for whom the
> > > information is for). The question is, where would you or how would you
> > save
> > > this "per user" information that needs to persist for as long as the
> > > presentation layer for a specific user is running? I'm not adverse to
> > having
> > > a global Application object that is an MTS component in the business
> > > services layer that is creatable by the presentation layer at start up
> > with
> > > methods to establish the beginning and end of the need by the
> presentation
> > > layer to communicate per se (albeit indirectly) with the "database".
> > >
> > > Can you offer some suggestions, ideas, comments or criticisms?
> > >
> > > Thank you.
> > >
> > > Darryll
> > >
> > >
> >
> >
>
>