I am out of my depth

[JK]

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

 

[Arvin Meyer [MVP]]

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

 

[JK]

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

 

[Tony Toews]

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

 

[Smartin]

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.

 

[Arvin Meyer [MVP]]

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

 

[JK]

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

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

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