Search results

I am sorry this is cross posting but these original posts did ask separate questions and it was suggested I start a new thread when they diverged. Here is the form explanation from the other thread: ----- Problems 1-6 are generic problems for a form (eg not legible). Then the specifics for...

For a bit more information I will attach a picture of one of the forms that is currently in use for a document. Problems 1-6 are generic problems for a form (eg not legible). Then the specifics for this form begins. "7 The name of the principal is missing in the document" This is on page 1 -...

As you know from the other thread there was not an answer to the question of how to achieve the form input with the correct schema. The closest answer was to hack together some VBA. https://access-programmers.co.uk/forums/showthread.php?p=1661631 I had the new design but no way of translating...

OK after creating new thread it looks like the better DB design would require a lot of custom VBA programming to display the forms (and possibly some resource intensive lookups etc). I will further investigate the change of DB design as a separate project but in the short term I will have to go...

I am inexperienced, but smart enough to seek guidance from those with more experience. By your very own words 'hacking together functionality with VBA' does not seem like the most efficient way to go with the forms and display. My point is that the correct DB structure actually makes the forms...

On average it is about 15-30 possible problems per document. The users don't have to select yes or no for everything, they just work through the list and tick the problems they note. This is definitely the way they want to do data entry. With the issues ordered by page number it is quick...

Thanks Pat. I will take on board all the field/naming conventions and include them in the final. It is always good to improve the basics. Unfortunately the drop down form list would not suit the current work flow. The users use the subform as a checklist/'cheat sheet' for the issues they...

Yes this is the behaviour I am trying to correct. And is described above as the old design but looking to change with the new design. This link is only to the "IssueAppliesTo" field - in other words each problem only applies to one particular document type and this is stored for ease of...

the original question probably still stands - how do I make a form, with check boxes to fit into the above structure?

OK I will update. I'm not sure if I understand this - when you say that all of the fields in tblIssuesMatrix should be their own fields in tblDocumentIssues isn't this just the current set up I have which seems inefficient? If there are 100 possible problems doesn't that mean there is at...

Thanks for this - I have tried adding the tblDocumentTypes twice in the relationship view (it automatically creates tbDocumentTypes_1) and unlinked/relinked. But when I close and open the database it automatically recreates the original link and orphans tblDocumentTypes_1. Is this what you...

I have experimented already and created a sample database which I had in another thread: https://access-programmers.co.uk/forums/showpost.php?p=1656049&postcount=8 The setup and relationships are not an issue it is creating the form to be able to have simple check boxes for users to select...

I suppose the question should be "is there a better way of achieving this?", with a clarification that better refers to a more elegant solution and aligning with the normalized setups. I did want to give extensive information, I can see frustrations when vague questions are asked which depend...

I am hoping for some advice about changing the set up of a database to follow better design rules and habits. The database I am working on has slowly grown and needs some changes which is a good time to look at the basic structure. The current requirement is that we receive a number of...

I am thinking this now belongs in the design forum as it is moving well away from VBA to very basic concepts.

OK I think I have the overall design correct then - I do already have some audit logging in another table which works well and I didn't want to include to muddy the waters. The extra ID fields are redundant but the numbers generated were originally a complicated system which didn't fit well...

OK I tried it out on a blank database to see if I could get the build right. I did not include an Audit Issues table but including a field in the Issues table as to which document type it applies to. I did add an extra table with the "document type" so this could be reused between the main...

OK - now is a good time to redesign as I have some other changes to make. Looking at that layout it looks to have an extra layer of "audit details" and "audit issues" and although it is good practice to record the audit details I think the table of audit issues is probably not relevant (or am I...

I suspected that the design was poor but let me add some more info. When entering the document details there is a table (tblDocumentLog) which contains the DocID and all relevant info to that document (Name of person completing etc) eg: DocID | Name | DocType | Site 5677 | John Smith...

I'm chasing how best to store the field names from all "true" fields from a table in an array (recordset? SQL?) and feedback of whether I am going about this correctly. We audit documents and each document can have any number of issues from a defined issues list (although this list grows over...