Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

User Interface, Button to prompt combo box and open forms 2

Status
Not open for further replies.

Colebean

Programmer
Jan 22, 2010
22
US
I am designing a document control system. This is my first time on a forum but I have run out of options! I am closing thread707-1587863 as requested by MajP and Duane. It was very lengthy and complicated, so I am consolidating it as follows. I have attached the database link, and the tables/relationships/forms info is listed after my problem description. You can refer to thread707-1587863 for my primary key explanation (how my document number is required to function).

I guess where I am having the most trouble is at the user interface part of the database. How do I create a form control that when selected it has a combo box appear with options that have different forms opened depending on the selection? Also, how do you have other columns on the combo box find previous and current records and use a formula to input values into the opened form? Finally, how do you have the previous record moved into an archive table, when a document is changed and the document version changes, so that only the most recent version is accessible?

Further Explanation/Details:

I need to have a form appear upon opening the database that has two functions 1. Start New Process and 2. Modify Existing Process. When the user selects one of these options I need a combo box to pop up with the options for Change Type (Create, Supplement, Pen and Ink, Revise), Document Type, Document Series, and Document Version.
When the user chooses Start New Process, I need different things to happen when each Change Type is selected:
"Create" will find the next record, by the user inputting the Document Type. Then it adds .001 to the previous record's Document Series for its' Document Series value and force v1.0 as its' Document Version, finally it would open the grouped form CREATE SOP.
"Supplement" would find the most recent record, by the user inputting Document Type and Document Version. Then it adds .1 to the previous Document Version, finally it would open up the group form SUPPLEMENT SOP.
"Revise" will find the most recent record, by the user inputting Document Type and Document Series. Then it adds 1 to the previous Document Version and forces the decimal value to be 0, finally it would open up the group form REVISE SOP.

When the user chooses modify existing process, I need the Change Type to pull up the group form associated with each Change Type and by the user inputting Document Type, Document Series, and Document Version to go to the existing record that needs to be modified.

TABLES:
Change Type
Change Type dbText PrimaryKey Indexed

Document Information
Document Type dbByte PrimaryKey Indexed Required
Document Series dbDecimal PrimaryKey Indexed
Document Version dbText PrimaryKey Indexed
Document Title dbText
Document Description dbText
Change Type dbText Indexed
Reason Change dbText
Purchase Order Number dbText
Purchase Order Approval Date dbDate
Estimated Delivery Date dbDate
Actual Delivery Date dbDate
Date Posted to Sharepoint dbDate
Date Submitted to EPA dbDate
Date of EPA Approval dbDate
Link to Document dbMemo
Date Document Provided for Signature dbDate
SOP Lead Name dbText
Date SOP Lead Signed dbDate
QAQC Evaluator dbText
Date QAQC Signed dbDate
Manager Name dbText
Date Manager Signed dbDate
Review Start Date dbDate
Review Complete Date dbDate
Reviewer Name dbText
Date Retired dbDate
Reason Retired dbText
Link to Archived Document dbMemo

Document Type
Document Type Number dbLong PrimaryKey Indexed
Type of SOP dbText

Draft Reviews
Review Number dbByte PrimaryKey Indexed
SOP Lead Name dbText
SOP Lead Date Assigned dbDate
Date SOP Lead Draft Complete dbDate
Field Evaluator dbText
Date Draft Provided for Field Eval dbDate
Date Field Eval Complete dbDate
QAQC Evaluator dbText
Date Draft Provided to QAQC dbDate
Date QAQC Evaluation Complete dbDate
Document Type dbByte PrimaryKey ForiegnKey Indexed Required
Document Series dbDecimal PrimaryKey ForiegnKey Indexed
Document Version dbText PrimaryKey ForiegnKey Indexed

Employees
EmployeeNo dbLong PrimaryKey Indexed
LastName dbText
FirstName dbText

Relationships:
Name: Change TypeDocument Information
Table: Change Type
Foreign Table: Document Information
PK: Change Type FK:Change Type

Name: Document InformationDraft Reviews
Table: Document Information
Foreign Table: Draft Reviews
PK: Document Type FK:Document Type
PK: Document Series FK:Document Series
PK: Document Version FK:Document Version

Name: Document TypeDocument Information
Table: Document Type
Foreign Table: Document Information
PK: Document Type Number FK:Document Type

Name: Document TypeDraft Reviews
Table: Document Type
Foreign Table: Draft Reviews
PK: Document Type Number FK:Document Type

Name: EmployeesDocument Information
Table: Employees
Foreign Table: Document Information
PK: EmployeeNo FK:SOP Lead Name

Name: EmployeesDraft Reviews
Table: Employees
Foreign Table: Draft Reviews
PK: EmployeeNo FK:SOP Lead Name

Forms:

INDIVIDUAL FORMS:
Document Information: Document Type, Document Series, Document Version, Document Title, Document Description, Change Type, Reason Change

Equipment: Purchase Order Number, Purchase Order Approval Date, Estimated Delivery Date, Actual Delivery Date

SOP Signatures: Date Document Provided for Signature, SOP Lead Name, Date SOP Lead Signed, QAQC Evaluator, Date QAQC Signed, Manager Name, Date Manager Signed

Draft Review: Review Number, SOP Lead Name, SOP Lead Date Assigned, Date SOP Lead Draft Complete, Field Evaluator, Date Draft Provided for Field Eval, Date Field Eval Complete, QAQC Evaluator, Date Draft Provided to QAQC, Date QAQC Evaluation Complete, Document Type, Document Series, Document Version {This is a Continuous form since there will be more than one review for each document}

GROUPED FORMS:
CREATE SOP: Document Information (Master Table); Tabs for: New Equipment, Draft Review, SOP Signatures, Finalized

SUPPLEMENT SOP: Document Information, Tabs for: Draft Review, SOP Signatures, Finalized

PEN AND INK SOP: Document Information, Tab for: Finalized

REVISE SOP: Document Information, Tabs for: Draft Review, SOP Signatures, Finalized
 
I expected to see a structure more like what I suggested earlier. I'm not sure how many work flow tables you have but I thought there would be one "lookup" table that has a record for each workflow task/step. The document and work flow tables would be related to a junction table of the primary key from the document table and the workflow lookup table.

I don't understand what these are
Colebean said:
Name: tblDocWorkFlowtblQaqcSigWF
Table: tblDocWorkFlow
Foreign Table: tblQaqcSigWF
PK: dwfDWFID FK:sigQaqcDWFID

Name: tblDocWorkFlowtblSharepointWF
Table: tblDocWorkFlow
Foreign Table: tblSharepointWF
PK: dwfDWFID FK:sptDWFID

Duane
Hook'D on Access
MS Access MVP
 
Wow I must have been tired last night. I broke up the signatures into workflows for each person but did not in the workflow table (oops). I also had the docWF (join table) reversed with the workflow lookup table. This should be right. There are 10 workflows. Sorry. Please let me know if this makes sense now. Thanks!!!

My computer internet at work is being very sllloooo When it decides it wants to upload to 4shared.com I will post the new link!! But the tables/relationships are as follows:

tblChangeCategory
sctChangeID dbLong PrimaryKey Indexed
sctChangeCategory dbText Indexed

tblDocInfo
docID dbLong PrimaryKey Indexed
docType dbInteger ForiegnKey Indexed Required
docSeries dbDecimal Indexed
docVersion dbDecimal Indexed
docTitle dbText Indexed
docDescription dbText Indexed
docChangeCategory dbText ForiegnKey Indexed
docChangeReason dbText
blnDocArchived dbBoolean
docTrackingNo dbSingle Indexed

tblDocType
DocumentTypeNo dbInteger PrimaryKey Indexed
SOPType dbText Indexed

tblDocWorkFlow
dwfDWFID dbLong PrimaryKey Indexed
dwfDocID dbLong ForiegnKey Indexed
dwfWrFID dbLong ForiegnKey Indexed
dwfDateStart dbDate
dwfDateComplete dbDate
dwfStatus dbText
dwfNotes dbText
dwfEmployeeNo dbLong ForiegnKey Indexed

tblDraftFieldEvalWF
fdrFieldID dbLong PrimaryKey Indexed
fdrWrFID dbLong ForiegnKey Indexed
fdrReviewNo dbInteger

tblDraftQaqcEvalWF
qdrQaqcID dbLong PrimaryKey Indexed
qdrWrFID dbLong ForiegnKey Indexed
qdrReviewNo dbInteger

tblEmployees
EmployeeNo dbLong PrimaryKey Indexed
LastName dbText
FirstName dbText

tblEpaWF
epaID dbLong PrimaryKey Indexed
epaWrFID dbLong ForiegnKey Indexed
epaApprovalStored dbText

tblLeadSigWF
sigLeadID dbLong PrimaryKey Indexed
sigLeadWrFID dbLong ForiegnKey Indexed

tblManagerSigWF
sigManagerID dbLong PrimaryKey Indexed
sigMgrWrFID dbLong ForiegnKey Indexed

tblNewEquipWF
equNewEquipID dbLong PrimaryKey Indexed
equWrfID dbLong ForiegnKey Indexed
equPONumber dbText
equPOApprovalDate dbDate

tblQaqcSigWF
sigQaqcID dbLong PrimaryKey Indexed
sigQaqcWrFID dbLong ForiegnKey Indexed

tblRetiredSop
arcRetireID dbLong PrimaryKey Indexed
arcDocID dbLong ForiegnKey Indexed
arcDateRetired dbDate
arcReasonRetired dbText
arcRetireDocLink dbMemo

tblSharepointWF
sptID dbLong PrimaryKey Indexed
sptWrFID dbLong ForiegnKey Indexed
sptDocLink dbMemo Indexed

tblSopAnnualReview
sarReviewID dbLong PrimaryKey Indexed
sarWrFID dbLong ForiegnKey Indexed
sarAdminEmail dbMemo

tblSopLeadWF
sdrLeadDraftID dbLong PrimaryKey Indexed
sdrWrFID dbLong ForiegnKey Indexed
sdrReviewNo dbInteger

tblWorkFlows
wrfWrFID dbLong PrimaryKey Indexed
wrfTitle dbText
wrfActive dbBoolean
wrfSeq dbInteger
wrkDaysReq dbInteger
wrfNotes dbText


Name: tblChangeCategorytblDocInfo
Table: tblChangeCategory
Foreign Table: tblDocInfo
PK: sctChangeCategory FK:docChangeCategory

Name: tblDocInfotblDocWorkFlow
Table: tblDocInfo
Foreign Table: tblDocWorkFlow
PK: docID FK:dwfDocID

Name: tblDocInfotblRetiredSop
Table: tblDocInfo
Foreign Table: tblRetiredSop
PK: docID FK:arcDocID

Name: tblDocTypetblDocInfo
Table: tblDocType
Foreign Table: tblDocInfo
PK: DocumentTypeNo FK:docType

Name: tblEmployeestblDocWorkFlow
Table: tblEmployees
Foreign Table: tblDocWorkFlow
PK: EmployeeNo FK:dwfEmployeeNo

Name: tblWorkFlowstblDocWorkFlow
Table: tblWorkFlows
Foreign Table: tblDocWorkFlow
PK: wrfWrFID FK:dwfWrFID

Name: tblWorkFlowstblDraftFieldEvalWF
Table: tblWorkFlows
Foreign Table: tblDraftFieldEvalWF
PK: wrfWrFID FK:fdrWrFID

Name: tblWorkFlowstblDraftQaqcEvalWF
Table: tblWorkFlows
Foreign Table: tblDraftQaqcEvalWF
PK: wrfWrFID FK:qdrWrFID

Name: tblWorkFlowstblEpaWF
Table: tblWorkFlows
Foreign Table: tblEpaWF
PK: wrfWrFID FK:epaWrFID

Name: tblWorkFlowstblLeadSigWF
Table: tblWorkFlows
Foreign Table: tblLeadSigWF
PK: wrfWrFID FK:sigLeadWrFID

Name: tblWorkFlowstblManagerSigWF
Table: tblWorkFlows
Foreign Table: tblManagerSigWF
PK: wrfWrFID FK:sigMgrWrFID

Name: tblWorkFlowstblNewEquipWF
Table: tblWorkFlows
Foreign Table: tblNewEquipWF
PK: wrfWrFID FK:equWrfID

Name: tblWorkFlowstblQaqcSigWF
Table: tblWorkFlows
Foreign Table: tblQaqcSigWF
PK: wrfWrFID FK:sigQaqcWrFID

Name: tblWorkFlowstblSharepointWF
Table: tblWorkFlows
Foreign Table: tblSharepointWF
PK: wrfWrFID FK:sptWrFID

Name: tblWorkFlowstblSopAnnualReview
Table: tblWorkFlows
Foreign Table: tblSopAnnualReview
PK: wrfWrFID FK:sarWrFID

Name: tblWorkFlowstblSopLeadWF
Table: tblWorkFlows
Foreign Table: tblSopLeadWF
PK: wrfWrFID FK:sdrWrFID
 
I'm still confused why you have multiple tables like tblLeadSigWF and tblManagerSigWF. If this was an orders and orders details application, you would not have an orders detail table for each different product or even each different product category.

When I see repeating similar tables with hard-coded values like Lead and Manager in their name, it generally suggests un-normalized structures.

Duane
Hook'D on Access
MS Access MVP
 
Can you answer the following very clearly? Tell me what it needs to do for each menu choice, not how to do the interface. That can be modified later. Be clear when you say add or increment, if you want to create a new record or increment an existing record. Especially be very clear in the Start SOP process for Create, Revise, Supplement.

Start SOP Process

Create
1. User selects type
2. determine max series for type
3. create a new record for choosen type.
4. for New record field values are
type = user selected type
Series = max series + .001.
Version = 1
Document Title = ?
Document description = ?
other fields
5 Open form "Create SOP" at the new record

Pen and Ink
Revise
Supplement

Modify SOP Process
Create
Pen and Ink
Revise
1. User picks record
2. Open "PenAndInkSOP"


I think I am very close, but it is actually a little more complicated then I thought. I am trying to tighten up the code and simplify it. First step make it work, second step make it work smartly.

Here is a demo.
The search form is ridiculously powerful. If your users can not find there records their hurting. You can sort by any field (think outlook), and then also filter by one or more type, series, and version. Filter and sort work together.

I think the modify SOP part is done. I demoed Create and revise for new sop but need the detail answers from above.

 
can you add a date time stamp to the doc info table? This is helpful so that when you create a new record in code you can then go to that record (because it is the one with the greatest date time). Since it is does in code you can not go to it by ID because you will not know what that ID is.

dtmDateTimeStamp
type: date
defaultvalue: now()
 
dhookom: I see what you mean with the tables being separate, I added a description type (devEvalType:Field, QAQC, SOP Lead in tblDraftEvalsWF instead of separate tables for each one, the same for sigFrom and tblSigWF).

MajP: I added the date/time stamp.

This is the link to the database and the tables/relationships are listed below:


tblChangeCategory
sctChangeID dbLong PrimaryKey Indexed
sctChangeCategory dbText Indexed

tblDocInfo
docID dbLong PrimaryKey Indexed
docType dbInteger ForiegnKey Indexed Required
docSeries dbDecimal Indexed
docVersion dbDecimal Indexed
docTitle dbText Indexed
docDescription dbText Indexed
docChangeCategory dbText ForiegnKey Indexed
docChangeReason dbText
blnDocArchived dbBoolean
docTrackingNo dbSingle Indexed
dtmDateTimeStamp dbDate

tblDocType
DocumentTypeNo dbInteger PrimaryKey Indexed
SOPType dbText Indexed

tblDocWorkFlow
dwfDWFID dbLong PrimaryKey Indexed
dwfDocID dbLong ForiegnKey Indexed
dwfWrFID dbLong ForiegnKey Indexed
dwfDateStart dbDate
dwfDateComplete dbDate
dwfStatus dbText
dwfNotes dbText
dwfEmployeeNo dbLong ForiegnKey Indexed

tblDraftEvalsWF
devID dbLong PrimaryKey Indexed
devWrFID dbLong ForiegnKey Indexed
devReviewNo dbInteger
devEvalType dbText ForiegnKey Indexed

tblEmployees
EmployeeNo dbLong PrimaryKey Indexed
LastName dbText
FirstName dbText

tblEpaWF
epaID dbLong PrimaryKey Indexed
epaWrFID dbLong ForiegnKey Indexed
epaApprovalStored dbMemo

tblEvalType
devEvalID dbLong PrimaryKey Indexed
devEvalType dbText Indexed

tblNewEquipWF
equNewEquipID dbLong PrimaryKey Indexed
equWrfID dbLong ForiegnKey Indexed
equPONumber dbText
equPOApprovalDate dbDate

tblRetiredSop
arcRetireID dbLong PrimaryKey Indexed
arcDocID dbLong ForiegnKey Indexed
arcDateRetired dbDate
arcReasonRetired dbText
arcRetireDocLink dbMemo

tblSharepointWF
sptID dbLong PrimaryKey Indexed
sptWrFID dbLong ForiegnKey Indexed
sptDocLink dbMemo Indexed

tblSigFrom
sfrID dbLong PrimaryKey Indexed
sfrSignatureID dbText Indexed

tblSigWF
sigID dbLong PrimaryKey Indexed
sigWrFID dbLong ForiegnKey Indexed
sigFrom dbText ForiegnKey Indexed

tblSopAnnualReviewWF
sarReviewID dbLong PrimaryKey Indexed
sarWrFID dbLong ForiegnKey Indexed
sarAdminEmail dbMemo

tblWorkFlows
wrfWrFID dbLong PrimaryKey Indexed
wrfTitle dbText
wrfActive dbBoolean
wrfSeq dbInteger
wrkDaysReq dbInteger
wrfNotes dbText


Name: tblChangeCategorytblDocInfo
Table: tblChangeCategory
Foreign Table: tblDocInfo
PK: sctChangeCategory FK:docChangeCategory

Name: tblDocInfotblDocWorkFlow
Table: tblDocInfo
Foreign Table: tblDocWorkFlow
PK: docID FK:dwfDocID

Name: tblDocInfotblRetiredSop
Table: tblDocInfo
Foreign Table: tblRetiredSop
PK: docID FK:arcDocID

Name: tblDocTypetblDocInfo
Table: tblDocType
Foreign Table: tblDocInfo
PK: DocumentTypeNo FK:docType

Name: tblEmployeestblDocWorkFlow
Table: tblEmployees
Foreign Table: tblDocWorkFlow
PK: EmployeeNo FK:dwfEmployeeNo

Name: tblEvalTypetblDraftEvalsWF
Table: tblEvalType
Foreign Table: tblDraftEvalsWF
PK: devEvalType FK:devEvalType

Name: tblSigFromtblSigWF
Table: tblSigFrom
Foreign Table: tblSigWF
PK: sfrSignatureID FK:sigFrom

Name: tblWorkFlowstblDocWorkFlow
Table: tblWorkFlows
Foreign Table: tblDocWorkFlow
PK: wrfWrFID FK:dwfWrFID

Name: tblWorkFlowstblDraftFieldEvalWF
Table: tblWorkFlows
Foreign Table: tblDraftEvalsWF
PK: wrfWrFID FK:devWrFID

Name: tblWorkFlowstblEpaWF
Table: tblWorkFlows
Foreign Table: tblEpaWF
PK: wrfWrFID FK:epaWrFID

Name: tblWorkFlowstblManagerSigWF
Table: tblWorkFlows
Foreign Table: tblSigWF
PK: wrfWrFID FK:sigWrFID

Name: tblWorkFlowstblNewEquipWF
Table: tblWorkFlows
Foreign Table: tblNewEquipWF
PK: wrfWrFID FK:equWrfID

Name: tblWorkFlowstblSharepointWF
Table: tblWorkFlows
Foreign Table: tblSharepointWF
PK: wrfWrFID FK:sptWrFID

Name: tblWorkFlowstblSopAnnualReview
Table: tblWorkFlows
Foreign Table: tblSopAnnualReviewWF
PK: wrfWrFID FK:sarWrFID
 
MajP: I made a description of what I want to do for the whole database so that I can keep everything straight. I pasted it below. Also, I just wanted to repeat how grateful I am for all of your help!!!

I want to make sure Duane doesn't see anymore glaring errors with the tables before I redo the forms, I will have the same basic layout as the beginning but they no longer work because of my table restructure (as Duane had warned me).

Nicole

Start New SOP Process
select docChangeCategory (Create, Pen and Ink, Revise, or Supplement)

Create
User selects docType
Determine max series for docType
Create a new record for chosen docType.
For New record field values are
docType = user selected type
docSeries = max series + .001.
docVersion = v1.0
docTitle = Text
docDescription =Text

Open form "Create SOP" at the new record
Tabbed form opens with Document Information as Master Table with:
docType
docSeries
docVersion
docTitle
docDescription
docChangeCategory(Create)
docChangeReason

Tabs are New Equipment (Create is the only process with New Equipment), Draft Reviews, Signatures, Finalized.

New Equipment(wrfTitle): user inputs
equPONumber
equPOApprovalDate
dwfDateStart(Estimated Delivery Date)
dwfDateComplete( Actual Delivery Date)

Draft Reviews(wrfTitle): The user is prompted if they would like to add a Draft Review. The user chooses devEvalType (Field, QAQC, SOP Lead). The Draft Review Form Opens and the User enters the appropriate fields for:
dwfDateStart(Date SOP Provided to Reviewer)
dwfDateComplete(Date Review is Finished)

Signatures(wrfTitle): Opens form and user inputs
dwfDateStart(Date SOP Provided for Signature)
dwfEmployeeNo(Name of Person Providing Signature)
dwfDateComplete(Date SOP Signature Complete)
under the appropriate sigFrom fields.


Finalize: Opens form and user inputs the following:

Under wrfTitle(Sharepoint)
dwfDateStart(Date SOP Provided to SOP Lead to post on Sharepoint)
dwfDateComplete(Sharepoint Posted Date)
sptDocLink(Document Link)

Under wrfTitle(EPA Document Approval)
dwfDateStarts(EPA Submitted Date)
dwfDateComplete(EPA Approval Date)
epaApprovalStored(Location of approval letter on F:Drive)

Pen and Ink
User inputs docType and docSeries
Determines max Version from docType and docSeries entries
Create a New record
For New Record:
docType = user selected type
docSeries = user selected type
docVersion = max version + .1
docTitle = Text (from previous version)
docDescription =Text (from previous version)

Open Form “Pen and Ink” at new record
Form opens with Document Information: Same as create, except:
docChangeCategory(Pen and Ink)

Subform Finalize(Same as create)

Supplement
User inputs docType and docSeries
Determines max Version from docType and docSeries entries
Create a New record
For New Record:
docType = user selected type
docSeries = user selected type
docVersion = max version + .1
docTitle = Text(from previous version)
docDescription =Text(from previous version)

Open Form “Supplement” at new record
Tabbed form opens with Document Information: Same as create, except:
docChangeCategory (Supplement)

Tabs are Draft Reviews, Signatures, Finalized.
Draft Reviews(Same as create)
Signatures(Same as create)
Finalize (Same as create)

Revise
User inputs docType and docSeries
Determines max Version from docType and docSeries entries
Create a New record
For New Record:
docType = user selected type
docSeries = user selected type
docVersion = max version + 1.0, the decimal .0 is forced
docTitle = Text(from previous version)
docDescription =Text(from previous version)

Open Form “Revise” at new record
Tabbed form opens with Document Information: Same as create, except:
docChangeCategory (Revise)

Tabs are Draft Reviews, Signatures, Finalized.
Draft Reviews(Same as create)
Signatures(Same as create)
Finalize (Same as create)

After New Record is created the previous record is cut and pasted into the Archive Table

Continue an Existing SOP Process

Create
Pen and Ink
Supplement
Revise

User picks record
User continues navigating through the existing SOP Process and "Continue an Existing SOP Process" until it is finished (“Location of approval letter on F:Drive” is entered)

Review
User picks record(same as Continue an Existing SOP Process)
Opens form “Review SOP”
User selects employee name, dwfDateStart(Review Start Date), and dwfDateComplete(Review Complete) Date
10 months from dwfDateComplete value, a notification email is sent to the
Administrator(sarAdminEmail)

Retire
User picks record(same as Continue an Existing SOP Process)
arcDateRetired = DateTimeStamp Now()
User inputs arcReasonRetired and arcRetireDocLink(location on Sharepoint “Retired SOPs” Folder)
User selects employee name
User Prompted “Do you want to retire this document?”
Yes=puts record into tblRetiredSop, No=Goes back to frmMainMenu
 
I think the tables are getting close. The docInfo is good enough for me to work with.

Do you have any feedback on the User interface?

Here are a couple of things.
1) Put a version number on your databases so that we are working on the same sheet of music
SOPControlSystem V.1 21Jan10.accdb
When I build a big db every day I make a big change I copy the database and save the old version then add a new version number. Then stick it in my backup folder
2)I think you need another couple of tables

tblRoles
roleID autonumber
roleName text

Are the people associated with a document always employees (reviewer, QAQC Evaluator, Manager)?

If so then I think the table needed is

tblDoc_Employee_Roles
docIDfk foreign key to documents
roleIDfk role foriegn key
employeeIDfk employee fk

if they are not always employees then instead of a employeeIDfk then it would be more like
tblDoc_Person_Role

docIDfk foreign key to documents
roleIDfk role fk
personName text name

now you can assign people (employees) to serve a role for a document.

If you are going to have employee ID as foreign key in a table, then you probably need yes no field in the employee table (blnActive). That way when you assign a person to a document you can pull from the employed people, you do not want to see in your drop down people who have left the company. But their names need to remain in the table because they will link back to old documents.

So now docInfo has only information about a document (not the process)
tblDowWkFlw has only information about workflow dates associated to a document
tblDoc_Employee_Roles has only information about people and their role to the document

The only other thing is some of the actions assigned to document. Not sure where these would go yet.
such as Purchase Order Number and reasoned retired
Right now I would leave them in the table.
 
MajP. The user interface works great!! It is extremely user friendly and you are right, if they can't find their document then they have bigger problems :) The people associated are always employees and I have ammended the tables accordingly. The other actions you mentioned are management tools. At the end of this I will create a form where they can search all of the document's histories, they specifically wanted PO Numbers and Reasons for retiring a document. Here's the updated database with the tables updates and file name format you use:

 
If you can now lock-down the docInfo table, and I will try to finish up the code to do your create, revise, penandink, supplement.

You can work on all the other tables and forms. Now that I looked at all your tables, I am not sure if the work flow tables are all needed.

You had these in your orginal table:
Purchase Order Approval Date dbDate
Estimated Delivery Date dbDate
Actual Delivery Date dbDate
Date Posted to Sharepoint dbDate
Date Submitted to EPA dbDate
Date of EPA Approval dbDate
Date Document Provided for Signature dbDate
Date SOP Lead Signed dbDate
Date QAQC Signed dbDate
Date Manager Signed dbDate
Review Start Date dbDate
Review Complete Date dbDate
Date Retired dbDate
Reason Retired dbText

I thought these are the actions you track for a document. So as duane pointed out these could be records instead of fields.

if you had a workflow table with this data

id Name
1 Purchase Order Approval Date
2 Estimated Delivery Date
3 Actual Delivery Date
Date Posted to Sharepoint
Date Submitted to EPA
Date of EPA Approval
Date Document Provided for Signature
Date SOP Lead Signed
Date QAQC Signed
Date Manager Signed
Review Start Date
Review Complete Date
Date Retired
14 Reason Retired

and then the junction table
tblDocWorkFlow
docID WorkFlowID DateStart DateComplete
1 1 1/1/2010 1/11/2010
1 2 1/2/2010 1/13/2010
2 14 3/1/09 3/1/09
This would allow you to do all the dates (workflows) for all documents. If a step is skipped or an additional item is needed this structure can handle it

So this is done in a subform by adding an workflow item from a pull down for a given document.

But then you have additional items of information associated with these work flows. I am still wrestling how I would handle this. For example in the equipWF table I have one field POnumber.

If I can have multiple purchase order numbers assigned to a step in the workflow then this may make sense. If not then I get little from having this in its own table, and the user interface becomes complicated. If you have only one to one relationships you have an overly complicated design. If you can only absolutely have one purchase order per document, then I think this data goes back into the document table.

Do not do anything yet, but think about it. Still a lot to do on the user interface just with the docinfo table, and that will not affect further development on the tables.
 
MajP: What if we take out the PO Number completely for the sake of sanity? I am working on the docInfo table tonight and the forms if time permits, if not I should put a dent in them tomorrow. Thanks for all of your help!!
 
I redid the tables the way you suggested, that really made things a lot simpler, I misunderstood Duane. I had an issue deciding what to do about the draft evaluations, since there are several reviews involving up to 3 people. Let me know if this isn't what you had in mind.
Thanks!!
Nicole
 
I will take a look at it tomorrow. But, I am having trouble myself figuring out how I would design the workflow tables. This is one of those times when a very normalized design may make building a user interface pretty convoluted. A normalized design normally reduces the amount of tables and fields, but now we have created a lot of tables with one to one relations. I have to think about this one.
 
On your decimal data types make sure you set the Scale.

The scale specifies the maximum number of digits that can be stored to the right of the decimal point. The scale must be less than or equal to the precision. You can specify a scale ranging from 0 digits to 38 digits, or use the default scale of 0 digits.

I do not understand why it defaults to zero but if you do not specify this then you will never store your series .oo1.
 
Another thing, all tables have a primary key. If you relate one table to another the primary key gets saved as a foreign key in the other table. You do not save another field.

So for changeCategory you have a autonumber pk. However in the tblDocInfo you save the text not the primary key. Do one or the other.

Either you save the primary key (autonumber) into the tblDocInfo, or you get rid of the autonumber in you changeCateogory table and make the strings (i.e. "Create") your primary key.
 
Is there ever more than one new equipment assigned to a document, or more than one purchase order?

Are there multiple evals for a specific doucument?
 

At this point I would scrap what you have, and start with the above database. It has several corrections, and the possible candidate tables.

1)Not sure how you got assigned this task, but I think you are way over your head. You need to invest in some good Access books. I would look at
Access Step by Step or Inside Out as an introduction
Once you got that get yourself the Access Desktop Developers Handbook by Litwin, Getz, and Gunderloy. Look online and get some older versions used (2000, 2003) and pick them up for under 10 bucks. My concern is you are not going to be able to maintain or understand what is done so far

2)All of the navigation and incrementing is done. It may need to be tweaked.

3)Get rid of your multiple forms, and use one form. This will make design much easier. Use code to hide tabs and controls, lock and unlock controls, change captions, require field filled in. This is demoed.


4)Now the tables. If it was me I would have the following related tables to docInfo. These would appear as continous subforms on the tabs

TblSignatures: a table holding all information about a signature
who (fk to employees)
role (fk to roles)
datesubmitted
dateComplete
So these fields from your original become parts of records in that table
Date Document Provided for Signature dbDate
SOP Lead Name dbText
Date SOP Lead Signed dbDate
QAQC Evaluator dbText
Date QAQC Signed dbDate
Manager Name dbText
Date Manager Signed dbDate

tblReviews: I think you may have this ok

tblLinks: I would throw all of your links into a single table
link description (fk to linkType table)
linkAddress

tblEquipment
if there is only one piece of equipment associated to a document then, I would throw all of this information into the doc info table. If not a seperate table to list multiple purchase orders and other fields related to a document.
Purchase Order Number dbText
Purchase Order Approval Date dbDate
Estimated Delivery Date dbDate
Actual Delivery Date dbDate

Now the tough one. There are a lot of additional dates (milestones) not associated with a review or a signature.
I would have a table milestones. (This was the original thought of workflows, where work flows where nothing but dates and description of events)

Eventdesc (fk to workflow table)
eventDate

so these fields become records in the above table:
Date Posted to Sharepoint
Date Submitted to EPA
Date of EPA Approval
Date Retired

Now this design provides a lot of flexibility to grow, but it will make showing information in phase very difficult. In other words it would be very difficult to have a tab "finalize", that shows sharepoint link information, share point date information becasue these fields are records and displayed in subforms such as
link information
milestone information
signatures
reviews
equipment

If that is not going to work, the solution is to move Link information, milestone information, back as fields in the doc info table. It is not very flexible, but will make showing those fields in phase and requiring action on them much easier.
 
Thanks so much MajP. I have a few access books and a step by step visual basic book, but I will definitely get the book you suggested. I have no idea why they are making me do this either, they said it is part of the learning process (ahhhh). But I have already learned an extraordinary amount on this journey. We do have only 1 piece of equipment and 1 PO for each SOP. I am going to try and make this work, starting with your table ideas. Again, I appreciate you holding my hand through this...
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top