Page 3 of 7 FirstFirst 1234567 LastLast
Results 31 to 45 of 93
  1. #31
    nchesebro's Avatar
    nchesebro is offline Competent Performer
    Windows 7 64bit Access 2010 64bit
    Join Date
    Dec 2010
    Posts
    108
    Maybe to just try to get on the same page here with what I am looking for as the end result:

    The database will be used to store Tour & Prospective Student data. The information will be collected as a single form or email from prospective student, and put into the database by one of the student workers. Between the time of initial input and the actual date of the tour, and admissions officer will look into our larger university database and check to see if there is any more information about that prospect there, in which case if there is additional information already on file, the officer, using the same form, will be able to fill in the information we have into the tour database. The record must be printed in a way that officer input is on a seperate page than the student worker input. I am assuming this can be done using a macro and report.

    The problem I am having is that I am trying to fool proof the form to make sure the input is all correct information (ie if the date for the tour is a thursday, automatically populate thursday in the day field, that way it is not confused, and we have a date on a thursday but the day was mistakenly put in as tuesday) and certain things are enabled based on other input (ie if they do not request meal tickets, disable meal ticket type and meal ticket quantity so data isnt accidentaly put in those fields)

    In case you were a bit lost on what the end goal was, I hope that kinda clears things up a bit.

  2. #32
    nchesebro's Avatar
    nchesebro is offline Competent Performer
    Windows 7 64bit Access 2010 64bit
    Join Date
    Dec 2010
    Posts
    108
    I am looking to produce a finished database with the following "features":

    -"Fool-Proof" Data Entry Form
    -Ability to print information seperately
    -Ability to add/change/delete tour times availiable on what days via a form
    -Ability to add/change/modify dates that tours will not be allowed to be scheduled (aka blackout dates)
    -Ability to cap tour numbers per time slot at a certain number, and modify that number as needed through a form.

    Are any of these so called "features" just unrealistic? These tasks should be able to be carried out by the average joe, rather than someone who knows anything about access to keep from having a database that needs a simple modification, but no one knowing how to do it.

  3. #33
    jzwp11 is offline VIP
    Windows 7 Access 2007
    Join Date
    Jun 2010
    Location
    Dayton, OH
    Posts
    2,901
    Do the notes refer to the prospective student or the tour?

  4. #34
    jzwp11 is offline VIP
    Windows 7 Access 2007
    Join Date
    Jun 2010
    Location
    Dayton, OH
    Posts
    2,901
    The table structure is critical to a successful relation database, therefore, you need to fix your tables before you even think about forms, queries and reports. With that said, we need to analyze the data you need to capture and how that data are related. After the analysis, we should be able to come up with a normalized table structure.

    So let's start the analysis with your current tblTour & its fields which are shown below:

    tblTour
    -tourGroup
    -tourSize
    -tourDate
    -tourDay
    -tourTime
    -tourOthers
    -tourAthleticTicket
    -tourAthleticTicketsNumber
    -tourAthleticTicketType
    -tourMealTickets
    -tourMealTicketsNumber
    -tourMealTicketsType
    -tourDifficultyStairs
    -tourDirectionsToLSSU
    -tourDirectionsGivenPhone
    -tourDirectionsRequestEmail
    -tourDirectionsSentEmail
    -tourDirectionsRequestMail
    -tourDirectionsSentMail
    -tourTakenBy
    -tourTakenDate
    -tourRequestFacultyAppointment1
    -tourFacultyMember1
    -tourTime1
    -tourLocation1
    -tourRequestFacultyAppointment2
    -tourFacultyMember2
    -tourTime2
    -tourLocation2
    -tourRequestFacultyAppointment3
    -tourFacultyMember3
    -tourTime3
    -tourLocation3
    -tourAthleticTicketMemoSent
    -tourConfirmatoinSent
    -tourGuide
    -tourAdmissionsOfficer
    -tourAdmissionsTerritory
    -tourAdmissionsStatus
    -tourCancellationNoShow
    -tourCancellationDate



    Analyzing...

    tblTour
    -tourGroup
    -tourSize
    -tourDate
    -tourDay
    -tourTime
    -tourOthers
    -tourAthleticTicket
    -tourAthleticTicketsNumber
    -tourAthleticTicketType
    -tourMealTickets
    -tourMealTicketsNumber
    -tourMealTicketsType
    -tourDifficultyStairs
    -tourDirectionsToLSSU
    -tourDirectionsGivenPhone
    -tourDirectionsRequestEmail
    -tourDirectionsSentEmail
    -tourDirectionsRequestMail
    -tourDirectionsSentMail
    -tourTakenBy
    -tourTakenDate
    -tourRequestFacultyAppointment1
    -tourFacultyMember1
    -tourTime1
    -tourLocation1
    -tourRequestFacultyAppointment2
    -tourFacultyMember2
    -tourTime2
    -tourLocation2
    -tourRequestFacultyAppointment3
    -tourFacultyMember3
    -tourTime3
    -tourLocation3
    -tourAthleticTicketMemoSent
    -tourConfirmatoinSent
    -tourGuide
    -tourAdmissionsOfficer
    -tourAdmissionsTerritory
    -tourAdmissionsStatus
    -tourCancellationNoShow
    -tourCancellationDate

    The fields shown in red are not needed. They can be determined/calculated if we set up the table structure properly.

    The fields shown in blue are a series of repeating groups which is a violation of normalization rules. The data should be captured as records in a related table, not as fields. Something like this:

    tblAppointments
    -pkApptID primary key, autonumber
    -foreign key field (to be determined)
    -fkPeopleID foreign key to tblPeople representing the faculty member who will be visited
    -fkLocationID foreign key to a table that holds all possible campus locations where an appt. can take place
    -tmeAppt (time for the appointment)


    The fields shown in magenta are also probably a repeating group and in violation of normalization rules. You would consider a table for tickets (generic)

    tblTickets
    -pkTicketID primary key, autonumber
    -foreign key to be detemined
    -fkTicketTypeID foreign key to tblTicketTypes which holds the type of tickets that can be obtained i.e. meal, athletic etc.
    -longNoOfTickets requested

    I'm not sure to what the mealtickettype and athletictickettype fields refer so you will have to explain further.

    The fields shown in green appear to be actions that have taken place. All possible actions should be stored as records in a table and then just relate them to whatever they correspond


    tblActions
    -pkActionID primary key, autonumber
    -txtAction

    For example, if the actions relate to a person relative to a tour they have signed up for, the table would look something like this:

    tblTourPeopleActions
    -pkTourPeopleActionID primary key, autonumber
    -fkTourPeopleID foreign key to the table that holds the person and tour junction/combination
    -fkActionID foreign key to tblActions
    -dteAction date action was taken

    -tourDifficultyStairs appears to be a way to capture any special requirements/needs of the person taking the tour. I would probably set up a table that holds the special requirements and relate those to the person/tour combination

    tblSpecialNeeds
    -pkSpecialNeedsID primary key, autonumber
    -txtSpecialNeed

    tblTourPeopleSpecialNeeds
    -pkTourPeopleSpecialID primary key, autonumber
    -fkTourPeopleID foreign key to the table that holds the person and tour junction/combination
    -fkSpecialNeedsID foreign key to tblSpecialNeeds

    The fields shown in brown appear to be other people related to the tour. All people should be in the people table and then related to the tour in tblTourPeople (as I have shown previously)

    I'm not sure what the difference is between tourTakenDate and tourDate.

    I'm not sure what these fields are either and what they relate to (the student, the tour or the combination):
    -tourAdmissionsTerritory
    -tourAdmissionsStatus

  5. #35
    nchesebro's Avatar
    nchesebro is offline Competent Performer
    Windows 7 64bit Access 2010 64bit
    Join Date
    Dec 2010
    Posts
    108
    Ok...

    I'm not sure to what the mealtickettype and athletictickettype fields refer so you will have to explain further.

    Meal Ticket Type = Lunch, Dinner
    Athletic Ticket Type = Basketball, Hockey, etc...

    I'm not sure what the difference is between tourTakenDate and tourDate.

    tourTakenDate = the date the tour reservation was taken
    tourDate = the day the tour is given to the student

    I'm not sure what these fields are either and what they relate to (the student, the tour or the combination):
    -tourAdmissionsTerritory

    -tourAdmissionsStatus


    The admissions territory is the part of the state of michigan from which the student goes to high school, or province/state if they come from outside of michigan. there are about 8 regions, each with their own unique 3 digit code. The admissions status is No, Has Applied, and Has Applied - Accepted.


    I will work on setting up the tables you outlined above, and will report back with what I have completed.

  6. #36
    jzwp11 is offline VIP
    Windows 7 Access 2007
    Join Date
    Jun 2010
    Location
    Dayton, OH
    Posts
    2,901
    Meal Ticket Type = Lunch, Dinner
    Athletic Ticket Type = Basketball, Hockey, etc...
    Since we have types and subtypes, that will require a different structure. Let's set up a table to hold the generic ticket types

    tblTicketTypes (2 records Meal, Athletic)
    -pkTicketTypeID primary key, autonumber
    -txtTicketType

    Then a related table to hold the various specific events

    tblTicketEventType
    -pkTicketEventTypeID primary key, autonumber
    -fkTicketTypeID foreign key to tblTicketTypes
    -txtTicketEventName

    You would then use pkTicketEventTypeID as a foreign key (fkTicketEventTypeID) in the table I proposed earlier

    tblTickets
    -pkTicketID primary key, autonumber
    -foreign key to be detemined
    -fkTicketEventTypeID foreign key to tblTicketEventTypes
    -longNoOfTickets requested

    I left the "foreign key to be determined" because I don't know if a perspective student requests these directly or whether it is in conjunction with a tour--you'll have to answer that question.

    tourTakenDate = the date the tour reservation was taken
    This does not belong in the tblTour but rather it relates to the person taking the tour, so it should probably go in tblTourPeople


    tourDate = the day the tour is given to the student This is the date of the tour is scheduled so it should be in tblTour.


    -tourAdmissionsTerritory
    Is directly related to the student & has nothing to do with the tour, so it should go in tblPeople

    -tourAdmissionsStatus
    Again, this field has nothing to do with the tour, but it is directly related to the student. However, since the admission status of the student can change over time, you have a one-to-many relationship (one student to many statuses of admission).

    First, a table to hold the possible admissions statuses:


    tblAdmissionStatus (3 records: Not applied, Has Applied, Accepted)
    -pkAdmissionStatusID primary key, autonumber
    -txtAdmissionStatus


    Now relate the admission status to the person


    tblPeopleAdmissionStatus
    -pkPeopleAdmissionStatusID primary key, autonumber
    -fkPeopleID foreign key to tblPeople
    -fkAdmissionStatusID foreign key to tblAdmissionStatus
    -dteStatus (date of the particular status)

  7. #37
    nchesebro's Avatar
    nchesebro is offline Competent Performer
    Windows 7 64bit Access 2010 64bit
    Join Date
    Dec 2010
    Posts
    108
    Ok. Before I start doing relationships, I want to double check and get a few last clarifications before moving on. Here are all my current tables (some things I had questions about, as noted in italics at the record in question):

    tblActions
    -pkActionID
    -txtAction

    tblAdmissionStatus
    -pkPeopleAdmissionStatusID
    -fkPeopleID
    -fkAdmissionStatusID
    -dteStatus

    tblAppointments
    -pkApptID
    -TBD (not sure what this fk is supposed to be...)
    -fkPeopleID
    -fkLocationID
    -tmeAppt



    tblPeople
    -ID (I am not sure what the pk is for this table, maybe pkPeopleID?)
    -AdmnissionsTerritory (should this be fkAdmissionsTerritory or some other prefix?)

    tblSpecialNeeds
    -pkSpecialNeedsID
    -txtSpecialNeed

    tblTicketEventType
    -pkTicketEventTypeID
    -fkTicketTypeID
    -txtTicketEventName

    tblTickets
    -pkTicketID
    -TBD (You made a reference to this earlier, and that you were unsure when students requested the tickets, the answer to that is they request tickets when making a tour reservation. Im guessing another table?)
    -fkTicketTypeID
    -longNoOfTickets

    tblTicketTypes
    -pkTicketTypeID
    -txtTicketType

    tblTour
    -ID (Should this be pkTourID?)
    -TourDate (not sure if this is fkTourDate)

    tblTourDays
    -pkTourDaysID
    -longDayNumber

    tblTourDayTimes
    -pkTourDayTimesID
    -fkTourDaysID
    -fkTourTimesID

    tblTourPeople
    -ID (Should this be pkTourPeopleID?)
    -TakenDate (not sure if this is fkTourDate)

    tblTourPeopleActions
    -pkTourPeopleActionID
    -fkTourPeopleID
    -fkActionID
    -dteAction

    tblTourPeopleSpecialNeeds
    -pkTourPeopleSpecialID
    -fkTourPeopleID
    -fkSpecialNeedsID

    tblTourTimes
    -pkTourTimes
    -dteTime

    Also, waaay back in this thread, for the information regarding taking the day from the date, and the available tour times, there were 3 or 4 tables regarding that. I think they should be placed in here too... correct me if I am wrong...
    Last edited by nchesebro; 01-04-2011 at 02:49 PM. Reason: accidentally hit enter too fast by luck of the keystroke...

  8. #38
    jzwp11 is offline VIP
    Windows 7 Access 2007
    Join Date
    Jun 2010
    Location
    Dayton, OH
    Posts
    2,901
    Also, waaay back in this thread, for the information regarding taking the day from the date, and the available tour times, there were 3 or 4 tables regarding that. I think they should be placed in here too... correct me if I am wrong...
    You are correct, they should be included we'll have to reference it in the tour time field of tblTour


    tblTourPeople
    -ID (Should this be pkTourPeopleID?)
    -TakenDate (not sure if this is fkTourDate)
    You can use pkTourPeopleID as the primary key field (you can actually name it whatever you want). I just like to use the table name as part of the primary key field name so I know where it is coming from (helpful when doing queries later on). Using just ID in all your tables is very confusing! You are missing fkPeopleID and fkTourID in the above table since you must relate the people to the actual tour they are taking

    TakenDate as you said is the date the tour reservation was taken
    Technically speaking taking the tour reservation is an action and probably can included be included in tblActions. And then you can just enter a record in tblTourPeopleActions so you probably do not even need TakenDate at all.

    tblPeople
    -ID (I am not sure what the pk is for this table, maybe pkPeopleID?)
    -AdmnissionsTerritory (should this be fkAdmissionsTerritory or some other prefix?)
    I would use pkPeopleID (again you can use whatever name you want).

    Regarding the AdmissionsTerritory, if you have a table set up that holds all of the Admission Territory info then yes you could use a foreign key so you do not have to type the territory code over and over again. It will save on errors as well

    tblAdmissionTerritory
    -pkAdmissionTerritoryID primary key, autonumber
    -AdmissionTerritoryCode
    (other fields related to the admission territory as needed)

    With the above, tblPeople would look like this:

    tblPeople
    -pkPeopleID primary key autonumber
    -fkAdmissionTerritoryID foreign key to tblAdmissionTerritory

    tblTickets
    -pkTicketID
    -TBD (You made a reference to this earlier, and that you were unsure when students requested the tickets, the answer to that is they request tickets when making a tour reservation. Im guessing another table?)
    -fkTicketTypeID
    -longNoOfTickets
    No new table is needed for the above. Since the tickets are related to the person/tour,you would use fkTourPeopleID (the foreign key to tblTourPeople)

    tblTour
    -ID (Should this be pkTourID?)
    -TourDate (not sure if this is fkTourDate)
    Again use whatever name you want for the ID field but pkTourID would be best since other tables refer to fkTourID.
    TourDate is just a date field that will hold the actual date of the tour, it is neither a primary or foreign key field.

    Now we need to associate the tour time in tblTour as previously mentioned

    tblTour
    -pkTourID primary key, autonumber
    -TourDate
    -fkTourDayTimesID

  9. #39
    nchesebro's Avatar
    nchesebro is offline Competent Performer
    Windows 7 64bit Access 2010 64bit
    Join Date
    Dec 2010
    Posts
    108
    Ok...

    I have one table that has me scratching my head...

    tblAppointments
    -pkApptID
    -TBD
    -fkPeopleID
    -fkLocationID
    -tmeAppt

    I cannot figure out what the TBD is actually supposed to be...

    also, I have a new database with just the tables in it, and I started building the relationships by dragging the pk to the fk, and enforcing referential integrity.



    Technically speaking taking the tour reservation is an action and probably can included be included in tblActions. And then you can just enter a record in tblTourPeopleActions so you probably do not even need TakenDate at all.

    I was a little confused by this, could you clarify a bit?

    I just uploaded a new copy of what I have on my side at: http://cid-9eda28db31e17672.office.l...px/Public?uc=1

  10. #40
    jzwp11 is offline VIP
    Windows 7 Access 2007
    Join Date
    Jun 2010
    Location
    Dayton, OH
    Posts
    2,901
    tblAppointments
    -pkApptID
    -TBD
    -fkPeopleID
    -fkLocationID
    -tmeAppt
    I left the field TBD because it depends on whether the appointments with faculty members are made by the perspective student ONLY in conjunction with a tour or not. You have to answer that question & based on your response will determine which foreign key field is applicable. If the appointments are made ONLY in conjunction with a tour that the perspective student is taking then the TBD=fkTourPeopleID. If the appointments can be made at any time (not in conjuction with a tour) then TBD=fkPeopleID.

    Technically speaking taking the tour reservation is an action and probably can included be included in tblActions. And then you can just enter a record in tblTourPeopleActions so you probably do not even need TakenDate at all.

    I was a little confused by this, could you clarify a bit?
    You said that you document when a perspective student requests a tour, in so doing you would assign them to a specific tour date/time. The person taking the request is performing an action relative to the person/tour combination. "Documenting the tour request" is an action so it would be a record in tblActions as would any other action. Since the action is tied to a tour/person combination, you need to join the action and tour/person in tblTourPeopleActions

  11. #41
    nchesebro's Avatar
    nchesebro is offline Competent Performer
    Windows 7 64bit Access 2010 64bit
    Join Date
    Dec 2010
    Posts
    108
    The student can request a faculty appointment at the time of reserving the tour, but the actual appointment itself is set up by office staff after the reservation is made.

    regarding tblActions, I now have this:

    tbActions
    -pkActionID
    -txtAction (2 Entries, Athletic Ticket Memo Sent, Confirmation Sent)

    so in essence, I would add another entry int txtAction, along the lines of "Tour Scheduled"?

  12. #42
    jzwp11 is offline VIP
    Windows 7 Access 2007
    Join Date
    Jun 2010
    Location
    Dayton, OH
    Posts
    2,901
    The student can request a faculty appointment at the time of reserving the tour, but the actual appointment itself is set up by office staff after the reservation is made.
    Then TBD=fkTourPeopleID

    When the request is made you would just select the faculty member, then the office staff can enter the appt. time at some later point.

    regarding tblActions, I now have this:

    tbActions
    -pkActionID
    -txtAction (2 Entries, Athletic Ticket Memo Sent, Confirmation Sent)

    so in essence, I would add another entry int txtAction, along the lines of "Tour Scheduled"?
    Exactly, but I think you had other fields in your original table that could also be considered as actions and thus would be records in the tblActions:

    -tourDirectionsToLSSU
    -tourDirectionsGivenPhone

    -tourDirectionsRequestEmail
    -tourDirectionsSentEmail
    -tourDirectionsRequestMail
    -tourDirectionsSentMail


    I also looked at you most recent database and noticed that in the tblAdmissionTerritory you had a field called AdmissionTerritoryRepresentative. This, I assume would hold a person's name, correct? If so, ALL people go in tblPeople. Now, with that we can have many students as well as a representative associated with each admission territory, we can use the fkAdmissionTerritoryID already in tblPeople to associate the representative to the territory. In other words we do not need to have the representative field in tblAdmissionTerritory at all.


    I've attached the updated database. I cleaned up your relationship window so that it is easier to read.

  13. #43
    nchesebro's Avatar
    nchesebro is offline Competent Performer
    Windows 7 64bit Access 2010 64bit
    Join Date
    Dec 2010
    Posts
    108
    Thank you for your help with that. I am curious about the tblPeople and how admissions advisors will be put in there. Are they just one of many people that will eventually populate that table? or will i need a seperate field for them as well?

    My problem right now is Normalization is all new to me (if it hasnt been outrageously obvious thus far), So I am having trouble trying to visualize how this is all going to come together and be stored when stuff is entered into a form... should I just not think about anything but these tables till they are done right and related to one another properly? This is a project I am currently working on, and yesterday, there were new ideas about a survey for students on tour to complete after the tour, and an assessment form for the tour guide to obtain qualatative data ( i.e. weather conditions, attitude of parent, attitude of student, etc) so i am guessing this will mean more tables? I am trying very hard to understand the process of normalization as you are providing feedback, and I am starting to understand some of what is going on. My biggest problem is being able to identify when a new table is necessary and when one is not, and something like that will probably come with experience.



    When the request is made you would just select the faculty member, then the office staff can enter the appt. time at some later point.
    The only problem with this is students can only request an appointment with a faculty member, selection and time of the faculty member is determined by office staff rather than students.



  14. #44
    jzwp11 is offline VIP
    Windows 7 Access 2007
    Join Date
    Jun 2010
    Location
    Dayton, OH
    Posts
    2,901
    I am curious about the tblPeople and how admissions advisors will be put in there. Are they just one of many people that will eventually populate that table? or will i need a seperate field for them as well?
    Any person who plays a role in your process would be included in tblPeople as just one of many. If you want the ability to distinguish different types of people in tblPeople, you can add 1 field that would join to a table that holds a list of roles.

    tblPeople
    -pkPeopleID primary key, autonumber
    -fkAdmissionTerritoryID foreign key to tblAdmissionTerritory
    -fkRoleID foreign key to tblRoles


    tblRoles
    -pkRoleID primary key, autonumber
    -txtRoleName

    You could have the following records in tblRoles:

    student
    admission representative
    faculty
    staff
    etc.

    The above structure only allows for a person to have 1 and only 1 role whether that is consistent with your application will be up to you.

    If a person could assume many roles then you would need a junction table that bring fkPeopleID & fkRoleID together.

    My problem right now is Normalization is all new to me (if it hasnt been outrageously obvious thus far), So I am having trouble trying to visualize how this is all going to come together and be stored when stuff is entered into a form... should I just not think about anything but these tables till they are done right and related to one another properly? This is a project I am currently working on, and yesterday, there were new ideas about a survey for students on tour to complete after the tour, and an assessment form for the tour guide to obtain qualatative data ( i.e. weather conditions, attitude of parent, attitude of student, etc) so i am guessing this will mean more tables? I am trying very hard to understand the process of normalization as you are providing feedback, and I am starting to understand some of what is going on. My biggest problem is being able to identify when a new table is necessary and when one is not, and something like that will probably come with experience.
    It is hard to visualize a table structure if this is your first exposure to it. Most times people approach Access like Excel. A spreadsheet is generally not normalized. So it will take some time to learn. I would recommend looking at other designs and follow other threads on the forum related to table design and you will learn quick enough. I started off as a newbie also (just many years ago ().

    The first thing I usually do is to write down what information I want to capture and then explore how the info is related. The other thing is that I try to lump similar things into general groups much like I did with your actions table. When things start to get specific, it generally means you are dealing with information that probably should be a record in a table rather than a field. I try to keep the field name generic and leave the specifics as records.

    It does sound like you will be expanding your database. Like any project, you need to define your requirements up front. I would suggest getting all interested parties together and layout what you want the database. Once an agreement has been reached (i.e. no more changes!), then work on the table structure.

    When the request is made you would just select the faculty member, then the office staff can enter the appt. time at some later point.
    The only problem with this is students can only request an appointment with a faculty member, selection and time of the faculty member is determined by office staff rather than students.
    When a student makes a request, how do they request it? Do they ask if they can meet with someone in a particular department etc.? You could add a field to include that and then leave the faculty member and time to the office staff to fill-in. You would at least document that there is an active request for an appointment. Of course, since you have many departments, you would have an applicable table and then use a foreign key.

  15. #45
    nchesebro's Avatar
    nchesebro is offline Competent Performer
    Windows 7 64bit Access 2010 64bit
    Join Date
    Dec 2010
    Posts
    108
    When a student makes a request, how do they request it? Do they ask if they can meet with someone in a particular department etc.? You could add a field to include that and then leave the faculty member and time to the office staff to fill-in. You would at least document that there is an active request for an appointment. Of course, since you have many departments, you would have an applicable table and then use a foreign key.

    http://www.lssu.edu/admissions/visit/

    This is the online form, you can see a list of checkboxes that have different reps. This form i think, will have changes made to it to accomodate what the office desires as a whole, but I could be wrong...

Page 3 of 7 FirstFirst 1234567 LastLast
Please reply to this thread with any new information or opinions.

Similar Threads

  1. Date Picker?
    By gazzieh in forum Forms
    Replies: 9
    Last Post: 02-09-2013, 09:35 AM
  2. Date Picker doesn't appear
    By revnice in forum Access
    Replies: 9
    Last Post: 01-09-2012, 08:36 AM
  3. date picker activex control
    By mr2000 in forum Forms
    Replies: 1
    Last Post: 10-13-2010, 09:51 AM
  4. Date picker
    By BI4K12 in forum Access
    Replies: 1
    Last Post: 06-09-2010, 11:11 AM
  5. Microsoft Date and Time Picker 6.0
    By That Crazy Hockey Dood in forum Forms
    Replies: 0
    Last Post: 07-25-2007, 03:22 PM

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