Welcome to SPN

Register and Join the most happening forum of Sikh community & intellectuals from around the world.

Sign Up Now!

I am out of my depth

Discussion in 'Information Technology' started by JK, Jul 28, 2006.

Tags:
  1. JK

    JK
    Expand Collapse
    Guest

    Hi All,



    I am in the process of converting 5 of my databases (thanks Tom) into Front
    and Back Ends when it occurs to me that that since I have to link the Back
    Ends in any case, I may be able to do away with duplications of tables in
    Back End sections.



    The question:

    Can one Front End look at more then one Back End at the same time and if so
    can it cause problems in the future replication or otherwise?



    Additional info:

    All of my databases looks at tables "Countries", "States", "Cites" for
    address, dialling & postal codes, local time etc, which in turn looks at
    other tables such as "Holidays Rules " (world-wide) and their dates,
    Daylight Saving (Summer) Time Rules date etc ect etc.



    "Countries" and "States" require very little maintenance but the "Cities"
    table which in fact a locations table (cities, towns, suburbs, villages and
    other locations, world wide) is constantly updated. It has around 19,000
    records so far.



    I am thinking about a possibility of creating one Back End for those tables
    as a separate database whereby each of the other databases' Front Ends will
    be able to look at and update it as necessary (the routines for it are
    already in most of the databases)



    At the moment each database has its own set (almost identical) except world
    "Holidays Dates" with is updated by one database, once a year, and is linked
    to the rest.



    Appreciate your views



    Regards/JK
     
  2. Loading...


  3. Arvin Meyer [MVP]

    Arvin Meyer [MVP]
    Expand Collapse
    Guest

    "JK" <Nobody@Home.com> wrote in message
    news:uTNI1C8rGHA.3648@TK2MSFTNGP03.phx.gbl...

    > The question:
    >
    > Can one Front End look at more then one Back End at the same time and if
    > so can it cause problems in the future replication or otherwise?


    One front-end can look at multiple back-ends and it shouldn't cause any
    problem with replication. What you are replicating is the back-end only, so
    there is only a link on the front-end to the data.

    > I am thinking about a possibility of creating one Back End for those
    > tables as a separate database whereby each of the other databases' Front
    > Ends will be able to look at and update it as necessary (the routines for
    > it are already in most of the databases)


    I have 15 separate departmental front-ends looking at 1 single back-end. One
    of those front-ends connects to 2 other back-ends (total 3 back-end
    databases) in 2 different 3rd party applications. It is better to keep all
    the data in one place if possible, but sometimes you have no choice.

    > At the moment each database has its own set (almost identical) except
    > world "Holidays Dates" with is updated by one database, once a year, and
    > is linked to the rest.

    --
    Arvin Meyer, MCP, MVP
    Microsoft Access
    Free Access downloads
    http://www.datastrat.com
    http://www.mvps.org/access
     
  4. JK

    JK
    Expand Collapse
    Guest

    Many thanks Arvin,

    In the meantime I splitted 4 databases and noticed a dramatic reduction in
    speed although both ends are on the same computer, the same is also true for
    functions that do not look at any data - I disabled the name tracking auto
    correct with significant improvement in speed (not sure about repercussions
    yet).

    I guess it is back to school for me.

    Thanks again
    JK




    "Arvin Meyer [MVP]" <a@m.com> wrote in message
    news:Oxs6Zd9rGHA.1272@TK2MSFTNGP05.phx.gbl...
    > "JK" <Nobody@Home.com> wrote in message
    > news:uTNI1C8rGHA.3648@TK2MSFTNGP03.phx.gbl...
    >
    >> The question:
    >>
    >> Can one Front End look at more then one Back End at the same time and if
    >> so can it cause problems in the future replication or otherwise?

    >
    > One front-end can look at multiple back-ends and it shouldn't cause any
    > problem with replication. What you are replicating is the back-end only,
    > so there is only a link on the front-end to the data.
    >
    >> I am thinking about a possibility of creating one Back End for those
    >> tables as a separate database whereby each of the other databases' Front
    >> Ends will be able to look at and update it as necessary (the routines for
    >> it are already in most of the databases)

    >
    > I have 15 separate departmental front-ends looking at 1 single back-end.
    > One of those front-ends connects to 2 other back-ends (total 3 back-end
    > databases) in 2 different 3rd party applications. It is better to keep all
    > the data in one place if possible, but sometimes you have no choice.
    >
    >> At the moment each database has its own set (almost identical) except
    >> world "Holidays Dates" with is updated by one database, once a year, and
    >> is linked to the rest.

    > --
    > Arvin Meyer, MCP, MVP
    > Microsoft Access
    > Free Access downloads
    > http://www.datastrat.com
    > http://www.mvps.org/access
    >
    >
     
  5. Tony Toews

    Tony Toews
    Expand Collapse
    Guest

    "JK" <Nobody@Home.com> wrote:

    >In the meantime I splitted 4 databases and noticed a dramatic reduction in
    >speed although both ends are on the same computer, the same is also true for
    >functions that do not look at any data -


    Yes, this is expected behavior.

    >I disabled the name tracking auto
    >correct with significant improvement in speed (not sure about repercussions
    >yet).


    Good.

    >I guess it is back to school for me.


    Just to save you some looking - For more information on performance
    visit my Access Performance FAQ page at
    http://www.granite.ab.ca/access/performancefaq.htm

    Tony
    --
    Tony Toews, Microsoft Access MVP
    Please respond only in the newsgroups so that others can
    read the entire thread of messages.
    Microsoft Access Links, Hints, Tips & Accounting Systems at
    http://www.granite.ab.ca/accsmstr.htm
     
  6. Smartin

    Smartin
    Expand Collapse
    Guest

    JK wrote:
    > Many thanks Arvin,
    >
    > In the meantime I splitted 4 databases and noticed a dramatic reduction in
    > speed although both ends are on the same computer, the same is also true for
    > functions that do not look at any data - I disabled the name tracking auto
    > correct with significant improvement in speed (not sure about repercussions
    > yet).
    >


    Great information re: auto correct. Thanks for including that.


    --
    Smartin
     
  7. Arvin Meyer [MVP]

    Arvin Meyer [MVP]
    Expand Collapse
    Guest

    Definitely read Tony's performance FAQ. One other speed killer that I should
    mention is the use of subdatasheets in your tables. Other than no indexes,
    itis probably the top performance killer. Turn them off. (Set them to [none]
    in the table's property sheet).
    --
    Arvin Meyer, MCP, MVP
    Microsoft Access
    Free Access downloads
    http://www.datastrat.com
    http://www.mvps.org/access

    "Smartin" <smartin108@yahoo.com> wrote in message
    news:SMOdnSTqF76GOFvZnZ2dnUVZ_t2dnZ2d@giganews.com...
    > JK wrote:
    >> Many thanks Arvin,
    >>
    >> In the meantime I splitted 4 databases and noticed a dramatic reduction
    >> in speed although both ends are on the same computer, the same is also
    >> true for functions that do not look at any data - I disabled the name
    >> tracking auto correct with significant improvement in speed (not sure
    >> about repercussions yet).
    >>

    >
    > Great information re: auto correct. Thanks for including that.
    >
    >
    > --
    > Smartin
     
  8. JK

    JK
    Expand Collapse
    Guest

    I don't have any subdatasheets, all search or sort fields are indexed, all
    subdatasheets are/were on "Auto", changing then as I go (ouch my finger
    hurts :)

    I need to remove some bells and whistles, possible even break up some forms
    into 2 or more, particularly those that have more than one subform based on
    some "heavy" queries - but so be it .

    I also noticed that having done the changes, The change in speed further
    noticeable after I restart the computer.

    Getting there ....

    Thanks again
    JK



    "Arvin Meyer [MVP]" <a@m.com> wrote in message
    news:OhuJ10FsGHA.3684@TK2MSFTNGP05.phx.gbl...
    > Definitely read Tony's performance FAQ. One other speed killer that I
    > should mention is the use of subdatasheets in your tables. Other than no
    > indexes, itis probably the top performance killer. Turn them off. (Set
    > them to [none] in the table's property sheet).
    > --
    > Arvin Meyer, MCP, MVP
    > Microsoft Access
    > Free Access downloads
    > http://www.datastrat.com
    > http://www.mvps.org/access
    >
    > "Smartin" <smartin108@yahoo.com> wrote in message
    > news:SMOdnSTqF76GOFvZnZ2dnUVZ_t2dnZ2d@giganews.com...
    >> JK wrote:
    >>> Many thanks Arvin,
    >>>
    >>> In the meantime I splitted 4 databases and noticed a dramatic reduction
    >>> in speed although both ends are on the same computer, the same is also
    >>> true for functions that do not look at any data - I disabled the name
    >>> tracking auto correct with significant improvement in speed (not sure
    >>> about repercussions yet).
    >>>

    >>
    >> Great information re: auto correct. Thanks for including that.
    >>
    >>
    >> --
    >> Smartin

    >
    >
     

Share This Page