Multiple front-ends to single back-end

[Guest]

Are there any particular issues with having multiple different front-ends
interacting with the same back-end?
I am contemplating a searching and reporting front-end for an existing
database that has another front-end used for data entry. The data entry front
end is heavily used by 3-4 agents all day. The reporting front-end will be
used by many more people but sporadically.
The only downside I see is that if I have queries that both front-ends need,
they will have to be duplicated.

 

[John W. Vinson]

The only downside I see is that if I have queries that both front-ends need,
they will have to be duplicated.

That's about it. Just two different frontends to maintain instead of one; the
backend will not be affected.

John W. Vinson [MVP]

 

[Arvin Meyer [MVP]]

I organized work departments around separate applications. In the
homebuilding industry database that I wrote, there were 15 front-ends (3 of
which were for maintenance) connected to a single back end. In addition we
had an asp front end connected to the same back-end and one of the
front-ends was connected to the back-end through a terminal server. We had a
total of 53 users with as many as 70 connections (several users had 2 or 3
front-ends open at once)

In over 7 years, we had no problems whatsoever that had anything directly to
do with the database itself. We did have some corruption problems from a bad
WiFi connection and also had a corrupt autonumber once (but that was a
Microsoft bug).

 

[Linq Adams via AccessMonster.com]

And remember, you don't really need to "duplicate" the queries, just import
them from one front end into the other.

 

[Guest]

Conversly, you can have multiple back ends used by one front end. We do
that here. One contains all common information, Contacts, Contracts,
Workflow schedules, etc. The other two applications each have their own
operational data, but the also link to the common back end for the common
data.

 

[John W. Vinson]

Conversly, you can have multiple back ends used by one front end. We do
that here. One contains all common information, Contacts, Contracts,
Workflow schedules, etc. The other two applications each have their own
operational data, but the also link to the common back end for the common
data.

That's often useful but there's one caveat: you cannot enforce referential
integrity between tables unless those tables are in the same backend.

John W. Vinson [MVP]

 

[Guest]

Yes, I am aware of that, John, but always good to point that out.
In this case, the two operational apps only use the data from the common BE
for info and validation. They do not modify any data in it.

For example we want to send out Invoices for Client XYZ and Properties owned
by XYZ. Client XYZ data and Property data is in the common BE but the
Invoicing is done from Billing BE. There can be 1 to N Units associated with
Client XZY.
(Multi Family Housing Utility Billing) Client is Management company,
Property is Apt complex, Unit is Apt.
Both operational apps need Client data and Property data, so it does not
make sense to try to keep the two BEs in alignment.
The other FE formats G/L info for clients and creates XML files for them to
download.

Basically, we just use queries with the common tables joined to get the
pertinent info.

The common FE is used to maintain the data in the common BE and set up the
work schedules.