There's no need to separate your data entry and 'search'. They can both be done on the same form. Especially if you use unbound forms.
My personal preference here is not to use bound forms unless you have a very strong understanding of how to prevent data getting into your database that you don't want. For instance. On one of your records you have no part name. I would assume a part name is a required element, in a bound form you would have to have a 'before update' and a 'before insert' event to cycle through your fields and determine whether they are necessary or not. I usually do this using the TAG property and doing something like:
Code:
dim ctl
for each ctl in me.controls
if instr(ctl.tag, "REQ") and isnull(ctl) then
smsg = smsg & ctl.name
endif
next ctl
if len(smsg) > 0 then
msgbox "The following fields are required" & vbcrlf & vbcrlf & smsg & vbcrlf & "Please try again", vbokonly, "ERROR ADDING RECORD"
exit sub
else
'go on to whatever check you're doing next
endif
Secondly, You have a ton of space chewed up unnecessarily, and this form will only work for people who have their screen resolution set to what you did your design with or a higher resolution. Anyone using a lower resolution will have to use the scroll bars on both the right and bottom to get to elements of your form. I would suggest trying to compact the UI as much as possible just to make it usable by a wider variety of users.
Third, never allow data entry to occur on your tables directly. That is a recipe for disaster. All your 'X table' buttons will allow anyone using the database to add anything they want to these tables or even accidentally alter existing records (or delete them) which will fry your data over time.
Fourth, if this database will be used by anyone but you, I would hide the tables, it's really a very small thing but it will prevent any novice from accidentally opening this database (by holding down the shift key) and deleting/causing damage to/renaming your tables.
Fifth, I would split this database into a front end and back end. So even if someone 'deletes' a table. They would actually have to go to the back end and delete the table as well which protects you from most new users doing something disastrous to your database.
Sixth. I would have a part transaction table, where you add and remove parts from your supply rather than just updating a number (which appears to me how you're doing it right now). This way you can calculate what you have on hand and also audit your usage, who used the part for what project, etc. Right now you're relying on them knowing the project name on your parts screen which is the reverse of how I would set this up. I would have a parts table, a project table, a receipts table (this could potentially be part of the 'project' table depending on need), which had a common 'part transaction' table recording both additions and subtractions from your inventory.
Your data structure looks ok though, field names appear to be relatively consistent, no special characters in the tables I looked at which is good, not using reserved words, also good.
rp