User Selectable Databases


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 5 of 5

Thread: User Selectable Databases

  1. #1
    Darryll D. Petrancuri Guest

    User Selectable Databases

    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


    Share on Google+

  2. #2
    Steve Berzins Guest

    Re: User Selectable Databases

    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
    >
    >



    Share on Google+

  3. #3
    Darryll D. Petrancuri Guest

    Re: User Selectable Databases

    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
    > >
    > >

    >
    >



    Share on Google+

  4. #4
    dsemen Guest

    Re: User Selectable Databases


    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
    >
    >


    Share on Google+

  5. #5
    Steve Berzins Guest

    Re: User Selectable Databases

    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
    > > >
    > > >

    > >
    > >

    >
    >



    Share on Google+

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center