Results 1 to 14 of 14
  1. #1
    sear100 is offline Novice
    Windows 7 64bit Access 2007
    Join Date
    Oct 2013
    Location
    London, UK
    Posts
    5

    NEW PROJECT - Patient List system: help with design of Tables and relationships

    I am a doctor and I'm creating a new List system for my Orthopaedic team in hospital. The goal is to create a robust list system which can manage the emergency and elective intake of patients of various consultants.

    I'm rebuilding an existing database which I've advanced quite far but realised limitations of due to the fundamental design limitations.

    Main tables description of purpose:

    tblPatientDatabase: core data about the patient is stored DOB etc

    tblPatientEpisode: data pertaining to each patient episode... Patients can have multiple episodes all of which start and stop.... whilst their episode is open they become an active record on the database "active".

    tblDailyrecords: for each day a patient is in hospital various data is recorded such as blood tests, clinical progress information, outstanding jobs, and other parameters pertaining to the level of severity of the patient status etc. This data is specific to each patient and specific to each episode.

    tblOperations: patients can undergo undergo operations which take place within a given patient episode - I have therefore linked

    tblConsultants: each patient must have an assigned consultant for every episode that they have.

    tlbTeamInfo: each patient is assigned to a Team - each team works for a specific consultant or consultants however sometimes teams look after patients belonging to consultants were not are not in their team.

    tblWard: patients are admitted to specific wards which relate to specific episodes. Obviously each ward will have multiple records of different patients have their "episodes" within the wards... However patients also move between wards during "episodes".



    I've created this JPEG demonstrating the proposed relationships - you can see the essence of the tables as well as some of the fields in the tables i'm creating. The sub-constituents of the individual tables are not that important at this stage

    Click image for larger version. 

Name:	relationships.jpg 
Views:	54 
Size:	90.1 KB 
ID:	14148

    Main Issues:

    1. Please can someone tell me if this is a correct start to the database based on the information I've provided in my description of the tables?

    2. I'm conceptually struggling with the idea that when patients move between wards and consultants.... That they would need a new record - in my present system it seems that only one consultant and ward can be ascribed to each episode... Can someone suggest a solution to this?

    3. Is there a more elegant way to deal with the relationship between the consultants and the teams? than the one that I have currently proposed? It needs to be as generic as possible as I'd like to use this database in as wide number of settings as possible...

  2. #2
    Dal Jeanis is offline VIP
    Windows 7 32bit Access 2010 32bit
    Join Date
    May 2013
    Location
    Dallas TX
    Posts
    1,742
    I looked over your design before getting to your questions. I noticed the same issues you're thinking about, and made the following comments.

    From my experience, a diagnosis is not something that happens once. It's an iterative process, right? So I'd break out tblEpisodeDiagnosis into a junction table rather than having a single field.

    Click image for larger version. 

Name:	diag3.PNG 
Views:	51 
Size:	5.8 KB 
ID:	14149

    Likewise, can't a patient be moved from ward to ward or room to room during one episode? Separate table with date/time rather than field.

    Can't a patient have more than one Consultant during an episode? Separate table.

    I'd shorten the names if possible. It's all a database, so tblPatients should be enough. Episodes are only had by patients - you're not recording any episodes your your doctors have - so just tblEpisodes should be enough.

    Are your "tblDailyRecords" really one per day, or can you have several some days? If so, perhaps tblProgressReports or tblObservations or something along those lines?

    Regarding tblTeamInfo, are your teams relatively set, or do they change constantly? If they aren't set, then you have to define the purpose of recording the team information at all. How is the team different from a bunch of consultants? You could record the individuals in the team exactly the way you record your consultants, if they're important enough to list individually. An RN becomes just another kind of consultant.

  3. #3
    ssanfu is offline Master of Nothing
    Windows XP Access 2000
    Join Date
    Sep 2010
    Location
    Anchorage, Alaska, USA
    Posts
    9,664
    Welcome to the forum
    Nice job on naming the fields/tables.
    No spaces, special characters or reserved words. Consistent naming convention.


    My thoughts:

    tblPatientDatabase: I would change the name to tblPatients. The patient table is not a database"

    I would remove the fields intEpisodeID and move intHospitalID to the "tblPatients" (tblPatientsEpisode) table.

    I would change the name from "blnSex" to "blnGender". Actually I would change the field type to text - field size = 1 and use M/F

    "dtmDateModified" and "dtmTimeModified" could be one field. You could make it a time stamp type field where the date/time is modified/updated any time a patient's info is modified. User can not/should not modify date/time.


    My $0.02

  4. #4
    sear100 is offline Novice
    Windows 7 64bit Access 2007
    Join Date
    Oct 2013
    Location
    London, UK
    Posts
    5
    Dear Ssanfu and Dal,

    I am so grateful for your help! You're suggestions are really helpful. I've gone away - brainstormed on what you and others have been saying and have come up with a new model.

    Click image for larger version. 

Name:	relationships4.jpg 
Views:	51 
Size:	123.7 KB 
ID:	14155

    To reply to specific suggestions

    Dal: you're absolutely right about the iterative process of achieving a diagnosis. Doctors tend to talk about "problems" --- which we have to deal with was the patients in hospital. E.g. one patient might have 1. Fractured wrist and 2. Urinary tract infection. So ...I've adpopted your suggestion - brilliant. I'll have to think about a means of displaying it in a workable way on a form... My thoughts extend to problems which arise and then get resolved within a patient's stay which are "problems" and sometimes sometimes not formal diagnosis which need to be listed to be dealt with but may may not need to be closed out for the final diagnosis at the end. I need to somehow also help people differentiate between problems which are active in which are "resolved" or retired


    Ssanfu:
    I'm unclear about your second sentence
    "I would remove the fields intEpisodeID and move intHospitalID to the "tblPatients" (tblPatientsEpisode) table."
    Is it resolved in my new Model?
    Please have a look over the new model - It's much more complicated but I think it makes much more sense!

  5. #5
    ssanfu is offline Master of Nothing
    Windows XP Access 2000
    Join Date
    Sep 2010
    Location
    Anchorage, Alaska, USA
    Posts
    9,664
    I'm unclear about your second sentence
    "I would remove the fields intEpisodeID and move intHospitalID to the "tblPatients" (tblPatientsEpisode) table."
    A table holds attributes of an entity. A patient (person) can have: a First Name, a Last Name, a DOB, a Gender, Hair color, eye color, .....
    But I've never seen a person's "intEpisodeID" or "intHospitalID". These two fields do not belong in "tblPatients".


    In my tables, I always have the PK as the first field, followed by any FK fields, then the rest of the fields.

    You have "tblConsultants" linked to "tblOperations" twice. You can remove "tblConsultants_1"

    I think you need a junction table between "tblEpisodes" and "tblWards".
    One ward can have many Episodes and one Episode could be in many wards.

    Also, you have what appears to be a FK to tblHospitals, but I do not see a table for Hospitals? (the field I recommended removing from tblPatients.)

  6. #6
    hrenee is offline Advanced Beginner
    Windows 7 64bit Access 2010 32bit
    Join Date
    Sep 2013
    Posts
    41
    I cant' really help as I'm new as well but I just finished downloading and going through this sample database http://www.rogersaccesslibrary.com/forum/topic291.html

    It happens to be for an OB/Delivery unit and thought it might be of some help. Especially with setting up your forms when you get there.

  7. #7
    Dal Jeanis is offline VIP
    Windows 7 32bit Access 2010 32bit
    Join Date
    May 2013
    Location
    Dallas TX
    Posts
    1,742
    Ssanfu - "Sex" is a physical attribute (not strictly binary, but construed as such), "Gender" is a social construct. In medicine, "Sex" is correct.

  8. #8
    ssanfu is offline Master of Nothing
    Windows XP Access 2000
    Join Date
    Sep 2010
    Location
    Anchorage, Alaska, USA
    Posts
    9,664
    Dal
    I've created an lot of applications and was requested to change "Sex" to "Gender". In a health care dB, had the same request.... but I skipped over this being for doctors/patient exams..

  9. #9
    sear100 is offline Novice
    Windows 7 64bit Access 2007
    Join Date
    Oct 2013
    Location
    London, UK
    Posts
    5
    Dear All,

    thank you for your very helpful suggestions!

    Replies to specific points:

    Hrenee: thanks for the database. I've had a look over it. I've acutally gone quite a long way with forms and reports before but I was always working with slightly inadequate database structure - this is why I'm starting again!!!

    ssanfu:
    Sorry to pick that comment out! It just didnt make sense to me at 4am (my eyes were burning with tiredness!).... hopefully your points are addressed?

    the Gender/Sex issue:
    I've reverted to my original use of Sex - acutally it's quite important in medicine (rarely people of different Gender need to be treated as their true sex (!))

    Thanks for introducing the idea of Junction table to me. It makes so much sense...!

    Anyway I have incorporated them into the new design which can be seen here:






    Click image for larger version. 

Name:	relationships5.jpg 
Views:	41 
Size:	149.2 KB 
ID:	14179


    Some new specific concerns,

    New area pertaining to "theatre lists"

    The database has rapidly expanded from my original simple conception. However it's getting to the stage where it will be able to do almost everything I hoped it could do. I am struggling in the area of "theatre lists".... The way operation theatres work is that "lists" of operations are grouped together - normally under one consultant. Operations are normally formed by the patient's own consultant but not infrequently are they operated on by other consultants who have space on their list.

    I'm struggling in this area to describe the relationships on the one hand between a patient who has an episode where they undergo one or more operations - and theatre lists which are assigned to consultants where in one or more consultants may undertake operations on patients who themselves normally belong to the named list consultant but may occasionally belong to different consultant than who's list it is.

    I suspect that I've done it wrong by creating a superfluous a join between the consultants table and the theatre lists table.... Just - how do I describe which consultant is in charge of the list? --- This is an independent phenomenon from the consultants looking after patients you see....ad whilst typically the patients on that list were or will become that consultant's concern they are not nessicarily.


    Logon-system

    I intend to build a logon system with a password so that changes in the database can be recorded by whichever user is logged on. Can you suggest how this might take place? I would ideally like it to involve tblStaff - such that any staff member can select themeselves on login... - The system should then log the fact that this user has gone to the system. Note... Not everyone in the staff file will be using the system is a nevertheless the theory would be the any person staff member who is listed should be able to logon. This thing said not all of them will use the system and not all of them will require password.

    The main reason behind this would be to allow default values in lots of areas which require users to declare who they are. I'd also like to use this logon information to automatically stamp onto records who is changing the database and what time they changed it time accruing a history as we go along so that changes can be tracke. From a design point of view - I'm uncertain how to begin.... does this mean that tblStaff needs to have a relationship with every table that records such data? e.g. tblEpisodes, tblAntibiotics etc etc?
    I have made one link to demonstrate what I'm intending to describe between tblStaff and tblAntibiotics.... although once again I suspect that I will need a junction table to Log the change. - If this is the case will I need multiple Junction tables between tblStaff and their respective partners e.g. tblPatient, tbleEpisode etc... Or is there a sneaky way to do it?

    For the default values i mentioned and for this as well.... is it possible to infer by some means once the user has Logged onto the system? - - - i.e some kind of current user table? or would this all be query/coding driven?

    Thanks for all your help


  10. #10
    Dal Jeanis is offline VIP
    Windows 7 32bit Access 2010 32bit
    Join Date
    May 2013
    Location
    Dallas TX
    Posts
    1,742
    LODESTONE

    First, I'd suggest that you write down, in one sentence of less than twenty words, what the primary purpose of the database is.

    When it comes to design decisions, use that as your lodestone. Any design decision that overcomplicates the primary mission should be scrapped. Any design decision that facilitates the mission should be encouraged.

    BEWARE OF MISSION CREEP

    How does the purpose of this database relate to theatre lists? Is this database primarily for documentation and reporting, or is it also for planning? If you describe, in as simple terms as possible, what purpose theatre lists have in your database, you'll probably answer your own question about how to structure them.

    If you are just recording activity regarding patients, then "managing" the theatre lists isn't part of the core mission of the database.

    As "Dirty Harry" Callaghan used to say, "A man's got to know his limitations." You can sink literally hundreds of hours into bells and whistles that don't add anything to the value of your database.

    So, consider your situation with regard to user access to the database. If you log 100% of the update activity, then maintaining control on which users can do what updates becomes less critical. On the other hand, if you tightly control who can do what, then logging becomes less critical.

    It's fairly easy to log what happens in a database. It's fairly easy to control who logs on to the database. However, the finer you try to control Access to forms and capabilities, the more complicated your technical infrastructure becomes.

    There are lots of examples out there on the internet of how to log updates, how to establish user-level security, and so on. Once you decide on a method, you need to implement that same method in every single form/screen you design.

    My lodestone for this kind of design is, "Use the simplest method that will achieve the desired effect, or an acceptable approximation thereof."

  11. #11
    sear100 is offline Novice
    Windows 7 64bit Access 2007
    Join Date
    Oct 2013
    Location
    London, UK
    Posts
    5
    LODESTONE

    First, I'd suggest that you write down, in one sentence of less than twenty words, what the primary purpose of the database is.

    Purpose: integrated handover system facilitating workflow for doctors and nurses to increase safety, efficiency and enable live audit.

    When it comes to design decisions, use that as your lodestone. Any design decision that overcomplicates the primary mission should be scrapped. Any design decision that facilitates the mission should be encouraged.

    BEWARE OF MISSION CREEP

    How does the purpose of this database relate to theatre lists? Is this database primarily for documentation and reporting, or is it also for planning? If you describe, in as simple terms as possible, what purpose theatre lists have in your database, you'll probably answer your own question about how to structure them.

    If you are just recording activity regarding patients, then "managing" the theatre lists isn't part of the core mission of the database.

    It's not a management process per say... but it relates very heavily to the clinical activites in a surgical speciality.

    As part of the purpose of the database is to audit our work ongoing the ability to see how many theatre lists are occurring and the number of operations that are occurring within them is critical. Also Junior doctors are responsible for preparing the patients for these operations so there needs to be an integrated means of controlling and representing these lists in the database...


    As "Dirty Harry" Callaghan used to say, "A man's got to know his limitations." You can sink literally hundreds of hours into bells and whistles that don't add anything to the value of your database.


    So, consider your situation with regard to user access to the database. If you log 100% of the update activity, then maintaining control on which users can do what updates becomes less critical. On the other hand, if you tightly control who can do what, then logging becomes less critical.

    This conceptually very valuable.... Of course the key is striking a happy medium.... I think that the process of logging is quite important as finding out who did what and when Is SO helpful retrospectively. Thus I think I will try to maximise what Is logged and minimise what Is restricted....



    It's fairly easy to log what happens in a database. It's fairly easy to control who logs on to the database. However, the finer you try to control Access to forms and capabilities, the more complicated your technical infrastructure becomes.

    There are lots of examples out there on the internet of how to log updates, how to establish user-level security, and so on. Once you decide on a method, you need to implement that same method in every single form/screen you design.

    I've started to look into this.... It's bit of a mire. I think i need to make the plunge and see if it starts to work! Havke a e you got any particular threads that would guide me in my quest?

    My lodestone for this kind of design is, "Use the simplest method that will achieve the desired effect, or an acceptable approximation thereof."

    Feeling quite overwhelmed a perhaps a bit dishearteded about where I'd like to go but... not knowing exactly how to make it work at this stage...Overall I feel like I need to get something out and working to prove that the concept works .... but it will be quite frustrating recognising what CAN be done versus what I can do at this stage (mainly because of time constraints)...

    Thanks for your support thusfar!

  12. #12
    Dal Jeanis is offline VIP
    Windows 7 32bit Access 2010 32bit
    Join Date
    May 2013
    Location
    Dallas TX
    Posts
    1,742
    FIRST, DON'T PANIC! (That's why I wrote that in ALL CAPS, so you won't panic! )

    There's a lot to know, but you don't need to know it all at once. Eat it like an elephant, one bite at a time.

    I happen to be about 18 months ahead of you on the learning curve, so I can cut down the number of things you have to think about to a few at a time. Understand your choices, make a decision (arbitrary if necessary), understand the steps involved in implementing, and just move along.

    You are unlikely to make the perfectly optimum decision (no one can), but you won't totally screw up either, because you've been smart enough to ask for help at the right place and time.


    LOG TABLES

    Okay, so let's assume you select an architecture that does 100% logging. You only have to select a design for that architecture/method once, then follow it in all the things you develop later.

    Here's Allen Browne's overview of one architecture for that -
    http://allenbrowne.com/AppAudit.html

    The sample code is all there, if you follow the links in the text. Browne's version requires you build a temporary table and a log history table for each table that you want to log changes regarding.

    Susan Harkins provides a different architecture here, that requires only a signle big log table (which may be better or worse, depending on the circumstances)-
    http://www.techrepublic.com/article/...o-access-data/

    Here's another version by Adam Evanovich. I haven't reviewed it much, but it looks workable.
    http://www.databasedev.co.uk/audit_trail.html

    Review those, and make a decision between them if you can. If none of them feel right, then google "MS Access audit trail", possibly with 2007 or 2010 to get more recent examples, and look for additional candidate architectures.

    The critical factor is that you, personally, must understand what the selected method is, and how and why it works. You are the guy who will have to support it, and if you select a mystery method, then you are toast. Burnt toast, jellyside down on your expensive Persian carpet. Get me?

    You should read the following briefly, but don't try to make a decision about them yet. Concentrate on selecting your logging method, above, because that method will have to be worked into every single form you build.


    APPLICATION WORKFLOW

    For any of the above, you will have to make sure that all database changes occur in forms, not in tables or queries. Which means that the user should only be able to navigate around the database by the use of a hierarchy of forms and reports that you have designed.

    To prevent sidestepping the forms, you will probably want to hide the nav pane and the ribbons. See this thread - https://www.accessforums.net/forms/h...orm-35876.html - for that code.

    You don't need to secure the nav pane until after you finish your design and development of the user forms. Generally, at logon (see below) I determine whether the person has developer-level access, and turn on/off the nav pane and ribbons accordingly. And, incidentally, this same security method can also enable you to implement form-level controls on who can do what.


    LOGONS AND LOGOUTS

    And you'll want to control access and usage with logons. - you can't log who did what if you don't know "who".

    However, from my layman's knowledge of hospital facilities and procedures, I believe you will not have PCs/terminals that are dedicated to individuals. As such, logging becomes uncertain.

    Sure, your administrators and doctors will have their own machines in their offices, but much of the admin db update work will be done in open-access areas, and staffers will be unlikely to consistently log in and out of the database all the time. As such, you may have to settle for a merely statistical-probability level of accuracy as to "who".

    One useful technique to improve this data is to set up an automatic logout after a certain number of minutes of database inactivity. This can synergize with your logging function - if you create a log record (or just capture the "last action time") whenever the user does something significant - open a form, report, or query, update a record, and so on - then you can use the last action time to determine if the database has been idle for more than X minutes.

    You do this by, on logon, opening a hidden form with a timer on it. The same form can keep track of userID and any other session info, or you could put that info in Tempvars (the more modern method). Every so often, the timer will kick off, and check whether the database should close. At which point, you pop a countdown message and close the database after an additional 1 minute or so.

    This should be designed to dovetail with your standard access procedures to any other IT applications. If users are already consistently logging on and off the LAN to use other applications, then there's some easy code to pick up the ID of whoever is logged onto the machine. If not, then worst case scenario, you can use the machine ID as a proxy for the staffer's ID, and at least know where the change was made from. Some sample code for getting user name is here https://www.accessforums.net/code-re...ame-38386.html


    DEPLOYMENT CONSIDERATIONS

    Since the database may be used by many staffers simultaneously, you will probably need to break it into frontend/backend. You don't have to do this until you get finished with the overall design and general testing, but it's something to know. The backend contains the data tables, including the log tables, whereas the front end contains the user forms and reports, and any temporary variables that are unique to a user session. Splitting the database prevents certain types of corruption and contention. There are some great free or inexpensive tools out there for managing deployment and maintenance of the front-ends. Again, leave these considerations until after you have an arguably deployable database.

    When you break it FE/BE, you can also choose to deploy the frontend as a compiled or runtime module (a distinction you don't have to learn about right now), and this will help secure the database against unlogged or unwanted changes, accidental or otherwise.

    You'll want to have periodic backups. Presumably these can be scheduled at the server level by your technical staff. Alternately, they can be kicked off by a scheduled task, or by some VBA code. However, this isn't trivial in your environment, since this application will presumably be active 24 hours a day. When you get to deployment, consult with your LAN IT guys, then if needed you can revisit this on the forums and talk it out for your best method.

  13. #13
    sear100 is offline Novice
    Windows 7 64bit Access 2007
    Join Date
    Oct 2013
    Location
    London, UK
    Posts
    5
    LOG TABLES

    Understood loud and clear.... That's the whole point of me going through this... most doctors dont have a damned clue about databases (even though they drive most of modern healthcare) so it's important for me to know my architecture thoroughly as you suggest.

    APPLICATION WORKFLOW

    Form Driven inputs ONLY: of course! have done this in previous simple databases.

    Sidestepping: Thanks for the links! To be honest most of the users will not know even how to do simple functions such as

    Tutorials: I also make videos in my spare time. In time for the application launch I'm going to create a short tutorial video which will explain how to do various functions and also educate about a few key windows shortcuts eg Ctl+S - tab to move between fields etc....
    I'm going to install this on the server with a link to the video via a button so that people can watch it again if required...

    LOGONS AND LOGOUTS

    And you'll want to control access and usage with logons. - you can't log who did what if you don't know "who".
    However, from my layman's knowledge of hospital facilities and procedures, I believe you will not have PCs/terminals that are dedicated to individuals. As such, logging becomes uncertain.

    Sure, your administrators and doctors will have their own machines in their offices, but much of the admin db update work will be done in open-access areas, and staffers will be unlikely to consistently log in and out of the database all the time. As such, you may have to settle for a merely statistical-probability level of accuracy as to "who".

    You're absolutely right here. Typically nurses log on in nursing areas at the beggining of the sfit and then the computer remains logged on for a period of 12 hours.... Doctors, nurses and other health professional then dip in and out using the computer as they visit the area. When I'm on call I need to access computers all over the hospital!

    One useful technique to improve this data is to set up an automatic logout after a certain number of minutes of database inactivity. This can synergize with your logging function - if you create a log record (or just capture the "last action time") whenever the user does something significant - open a form, report, or query, update a record, and so on - then you can use the last action time to determine if the database has been idle for more than X minutes.

    You do this by, on logon, opening a hidden form with a timer on it. The same form can keep track of userID and any other session info, or you could put that info in Tempvars (the more modern method). Every so often, the timer will kick off, and check whether the database should close. At which point, you pop a countdown message and close the database after an additional 1 minute or so.

    This is something I was thinking of implimenting (I was going to figure out the details at a later stage). I think I will have to be quite a short window for log out inactivity.... Doctors are famous for logging into systems and walking away (i myself included).
    I hadn't thought of the countdown message pop up... thats a very smart idea!

    This should be designed to dovetail with your standard access procedures to any other IT applications. If users are already consistently logging on and off the LAN to use other applications, then there's some easy code to pick up the ID of whoever is logged onto the machine. If not, then worst case scenario, you can use the machine ID as a proxy for the staffer's ID, and at least know where the change was made from. Some sample code for getting user name is here https://www.accessforums.net/code-rep...ame-38386.html

    I am aware of these kinds of techniques....I think i'm going to have to make a second passthrough log on system however.... capturing the machine code is also a very helpful means of auditing changes....I'll impliment this


    DEPLOYMENT CONSIDERATIONS

    Since the database may be used by many staffers simultaneously, you will probably need to break it into frontend/backend. You don't have to do this until you get finished with the overall design and general testing, but it's something to know. The backend contains the data tables, including the log tables, whereas the front end contains the user forms and reports, and any temporary variables that are unique to a user session. Splitting the database prevents certain types of corruption and contention. There are some great free or inexpensive tools out there for managing deployment and maintenance of the front-ends. Again, leave these considerations until after you have an arguably deployable database.

    This is a definite! There's no point in having the database if it's not multiuser. This is one of the key advantages over our current (retarded) word based handover system....and of course there's the issue of some bozo going and deleting the backend!

    When you break it FE/BE, you can also choose to deploy the frontend as a compiled or runtime module (a distinction you don't have to learn about right now), and this will help secure the database against unlogged or unwanted changes, accidental or otherwise.

    I'll read up on this in terms of compiled or runtime...

    You'll want to have periodic backups. Presumably these can be scheduled at the server level by your technical staff. Alternately, they can be kicked off by a scheduled task, or by some VBA code. However, this isn't trivial in your environment, since this application will presumably be active 24 hours a day. When you get to deployment, consult with your LAN IT guys, then if needed you can revisit this on the forums and talk it out for your best method.

    Again was planning but thanks for stating it loud and clear! It's like you've read my design brief in my head!

    Thanks again Dal.... I'll keep pluggin away and get back to you

  14. #14
    Dal Jeanis is offline VIP
    Windows 7 32bit Access 2010 32bit
    Join Date
    May 2013
    Location
    Dallas TX
    Posts
    1,742
    Glad to see that I've captured the technical and workflow environment accurately. Post again when you have a specific design issue.

Please reply to this thread with any new information or opinions.

Similar Threads

  1. New System Design
    By tweety in forum Database Design
    Replies: 4
    Last Post: 11-19-2012, 01:54 PM
  2. Help With Patient Tracking Database Design
    By wkenddad in forum Programming
    Replies: 2
    Last Post: 04-25-2012, 09:15 PM
  3. Appointment system Design
    By monkeyhead in forum Database Design
    Replies: 1
    Last Post: 04-02-2012, 09:10 AM
  4. reservation system for class project
    By AdamVT in forum Access
    Replies: 5
    Last Post: 12-21-2011, 03:15 PM
  5. Project Involving Table Relationships
    By annemrosenberg in forum Access
    Replies: 30
    Last Post: 07-25-2011, 07:22 PM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Other Forums: Microsoft Office Forums