multiple back-ends
in [Tables]
|
From: Irene_58 on 2 Mar 2010 06:00 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" <Irene58(a)discussions.microsoft.com> wrote in message > news:A7A94706-39A9-4BFF-AA18-15D20BFC4B52(a)microsoft.com... > > 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 > > > . > |