A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Database Design
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

multiple back-ends



 
 
Thread Tools Display Modes
  #1  
Old February 10th, 2010, 07:50 PM posted to microsoft.public.access.tablesdbdesign
Irene_58
external usenet poster
 
Posts: 4
Default multiple back-ends

Hi,
I have 3 or 4 databases developed separarely over the past couple of years
covering different areas of company activities - project monitoring, support
call monitoring, QHSE monitoring etc. The company has grown and I'm looking
to consolidate and distribute these. I'd intended to split them into FE/BE
so that the just the appropriate FEs could be installed on any user's PC and
the back-ends would reside on the server. I'd thought at first that I could
have a "core" BE with e.g. a staff and client table and activity specific
BEs. But the activity tables have the core tables PKs as FKs. Does this
mean I have to put all the tables into 1 BE? or am I missing something?
--
Irene
  #3  
Old February 10th, 2010, 09:37 PM posted to microsoft.public.access.tablesdbdesign
Jeff Boyce
external usenet poster
 
Posts: 8,621
Default multiple back-ends

Irene

If you haven't gotten a response yet covering your question about PKs and
FKs, here's some thoughts...

If you are saying that each of your (3 or 4) databases have "core" tables,
and those cores are the same topics, but the data in each "core" table is
different, from app to app, then yes, you have a potential issue in
connecting the core records with their respective child table records.

For example, if all dbs have a core tblPerson table, but App1 has John Doe
as PersonID=1, while App2 has Bill Smith as PersonID=1, and so on, then you
clearly cannot expect the non-core tables that point to tblPerson to have
the correct foreign keys (most of the time).

I guess I'm having trouble visualizing what you mean by "the activity tables
have the core tables PKs as FKs". Is that the same as saying that the
activity tables are your "child" tables?

More info, please...

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.

"Irene_58" wrote in message
...
Hi,
I have 3 or 4 databases developed separarely over the past couple of years
covering different areas of company activities - project monitoring,
support
call monitoring, QHSE monitoring etc. The company has grown and I'm
looking
to consolidate and distribute these. I'd intended to split them into
FE/BE
so that the just the appropriate FEs could be installed on any user's PC
and
the back-ends would reside on the server. I'd thought at first that I
could
have a "core" BE with e.g. a staff and client table and activity specific
BEs. But the activity tables have the core tables PKs as FKs. Does this
mean I have to put all the tables into 1 BE? or am I missing something?
--
Irene



  #4  
Old February 10th, 2010, 10:13 PM posted to microsoft.public.access.tablesdbdesign
Stop$teve
external usenet poster
 
Posts: 76
Default multiple back-ends


"Steve" schreef in bericht ...
Yes, 1 BE. You want to do that anyway so you can create queries, forms and reports across multiple activities.


It depends $teve...

but...
Get lost $teve. Go away... far away....
No-one wants you here... no-one needs you here...

OP look at http://home.tiscali.nl/arracom/whoissteve.html
(Website has been updated and has a new 'look'... we have passed 11.000 pageloads... it's a shame !!)

For those who don't 'agree' with this mail , because $teve was 'helping' with his post...
We warned him a thousand times... Sad, but he is not willing to stop advertising...

He is just toying with these groups... advertising like hell... on and on... for years...
oh yes... and sometimes he answers questions... indeed...
and sometimes good souls here give him credit for that...

== We are totally 'finished' with $teve now...
== Killfile 'StopThisAdvertising' and you won't see these mails....

Arno R


  #5  
Old February 10th, 2010, 10:15 PM posted to microsoft.public.access.tablesdbdesign
John W. Vinson
external usenet poster
 
Posts: 18,261
Default multiple back-ends

On Wed, 10 Feb 2010 10:50:01 -0800, Irene_58
wrote:

Hi,
I have 3 or 4 databases developed separarely over the past couple of years
covering different areas of company activities - project monitoring, support
call monitoring, QHSE monitoring etc. The company has grown and I'm looking
to consolidate and distribute these. I'd intended to split them into FE/BE
so that the just the appropriate FEs could be installed on any user's PC and
the back-ends would reside on the server. I'd thought at first that I could
have a "core" BE with e.g. a staff and client table and activity specific
BEs. But the activity tables have the core tables PKs as FKs. Does this
mean I have to put all the tables into 1 BE? or am I missing something?


I think the nub of your problem is - as you have evidently gathered - that
Relationships with referential integrity enforced can only be established
between tables in the same backend. Unless there is some very good reason to
do otherwise (such as the size of the backend approaching the 2GByte limit, or
really critical security issues) I'd use a single backend; although you can
create queries joining tables across two backends, performance will suffer.
And you *do* lose referential integrity.

You might want to look into SQL Server Express as a shared backend.
--

John W. Vinson [MVP]
  #6  
Old March 2nd, 2010, 12:00 PM posted to microsoft.public.access.tablesdbdesign
Irene_58
external usenet poster
 
Posts: 4
Default multiple back-ends

I'm new to using the community and, embarrisingly, I seem to have linked to a
old snapshot page - so I didn't realise anyone had replied. Thanks for
replying, and sorry for the delay in getting back to you.

Simplified: I have a tStaff and a tJobNo table that I consider "core"
because all our company info is in it (part of the main job management db).
I have an old db for handling quality issues. It also had a tStaff table and
a tQIssue table which had a look-up / reference to the tStaff table for the
person raising the issue. I want to amalgamate the 2 dbs, and I'd though to
have a back-end specific for the quality db with tQIssue but with tStaff in
the main db. However, I don't see how to reference the main tStaff from the
quality back-end.
(My data isn't that huge - I can just put everything in 1 back-end. I just
want to be sure what's the best way to handle it.)


--
Irene


"Jeff Boyce" wrote:

Irene

If you haven't gotten a response yet covering your question about PKs and
FKs, here's some thoughts...

If you are saying that each of your (3 or 4) databases have "core" tables,
and those cores are the same topics, but the data in each "core" table is
different, from app to app, then yes, you have a potential issue in
connecting the core records with their respective child table records.

For example, if all dbs have a core tblPerson table, but App1 has John Doe
as PersonID=1, while App2 has Bill Smith as PersonID=1, and so on, then you
clearly cannot expect the non-core tables that point to tblPerson to have
the correct foreign keys (most of the time).

I guess I'm having trouble visualizing what you mean by "the activity tables
have the core tables PKs as FKs". Is that the same as saying that the
activity tables are your "child" tables?

More info, please...

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.

"Irene_58" wrote in message
...
Hi,
I have 3 or 4 databases developed separarely over the past couple of years
covering different areas of company activities - project monitoring,
support
call monitoring, QHSE monitoring etc. The company has grown and I'm
looking
to consolidate and distribute these. I'd intended to split them into
FE/BE
so that the just the appropriate FEs could be installed on any user's PC
and
the back-ends would reside on the server. I'd thought at first that I
could
have a "core" BE with e.g. a staff and client table and activity specific
BEs. But the activity tables have the core tables PKs as FKs. Does this
mean I have to put all the tables into 1 BE? or am I missing something?
--
Irene



.

 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 02:22 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.