I am setting up a database for our hunting club, plus learning access along the way...ouch
I want the database to contain all of the deer observed along with their locations, when the user enters the data it will go as buck/doe/fawn/unknown and they will also enter the location where the deer was observed. The location could be a stand located at various different places on the property or a stand could be located on a food plot.
Here is where I am confused, I got to this point and really just don't know the best path to follow. I have followed much of the normalization techniques and set up relationships. I am working with a form (frmEnterNewStand) to add the stands to the database, what I need is a single combo box with choices that come from two tables (tblProperty Sections for stands not located on food plots) and (tblFoodplots for stands located on food plots). But couldn't figure that one out. So I attempted to add food plots as another entry but things started getting messy.
Since I am new to this I don't even know the right questions to ask, but I just cannot figure out the best way to organize this to be able to enter data easily then access the data easily.
I know we will want to perform queries to get statistics on, i.e. how many deer were observed blah blah blah, we will also want to query the food plots as well, how many deer were seen on food plot 1 for example, and what time of day. We will also keep up with other food plot parameters.
I have been taking the Udemy course and have several books, but my mind is blown, any help would be appreciated.
I am going to include an example map of our property, the blue numbers are different sections for the property (tblPropertySections), the yellow S numbers are Stand 1, 2 etc, the orange F numbers are Food Plot 1, 2 etc.
Also included are my current screenshots of what I have so far. I was going to try to post images but I need at least 10 reputation points i guess.
NOt sure what else I need to provide but I will say thank you in advance
tim
thank you
tim
I think you should start simple on this and add complexity as needed.
From my reading of the problem the main outcome is a database that records deer sightings. The easiest possible "database" is just a table that lists the sighting, and associated info.
For example:
ID, Date, Time, DeerType, Location, SeenBy, Comments
1, 1/1/2015, 11:45pm, "Doe", "Behind the shed", "Garry Abblet", "After a few beers Garry went for a slash and saw a deer"
Start with that and then worry about what needs to be added. I know a single table isn't the most exciting database to learn about, but you should follow a philosophy of the simplest solution usually being the best.
Access forms are essentially the visual representation of tables. In fact, if users were just computers you would not need a user interface but can manage processing (edit, add, save, delete) through code. The combo box form control is the tool needed to select corresponding data from other tables, specifically foreign keys.
As you point out, a Stand can either be on a Property Section or Food Plot. So in the tblStands table you can carry two foreign keys: Property Section ID and Food Plot ID.
Then, on their corresponding forms of tblStands the IDs wold be stored/bounded in combo boxes whose RowSources are a queries of the underlying tables:
SELECT id, PropertySectionName FROM tblPropertySections
SELECT id, FoodPlotName FROM tblFoodPlots
Now, computers would know which ID to pick but not humans who would need names/titles to help identify which item to select. Fortunately, combo boxes come with a special hidden column feature where the IDs can be hidden from view but its related name is presented on the form. However, the ID is stored in table. You set this up with the wizard when you select and position combo boxes.
Manually, or no-wizard approach, you do the following in Property Sheet of selected combo box:
Format tab
Column Count: 2 (or any greater than 2 depending on RowSource query)
Column Width: 0"; 1" (or any non-zero that fits into combo box's width)
Data tab
Control Source: PropertySheetID (or FoodPlotID)
Row Source: (see above queries)
Row Source type: table/query
Bound column: 1
Altogether, users will navigate to frmEnterNewStand and choose if the Stand is on Property Section or Food Plot by entering one combo box and not the other (leave label instructions as needed, since users are human).
Related
I'm an intern student at a company that does both wiring and aircon services. The job that they gave me was to make a database for them. I don't have any experience in anything related to databases.
So, I started to look up videos and stuff to at least learn a bit about databases and made something that works and I made it after 1.5 months of learning.
in the database that I created,
I have 1 table (CustomerDetailsT):
CustomerID (pk)
CustomerName
PhoneNumber
Address
Aircond (type and model of ac,ex: WM daikin 1.0HP)
AcDetails (what has been done for the ac.)
Others (yes/no) (Wiring, installing a fan and so on)
WhatHasBeenDone (shows what has been done for others)
Then 3 queries (CustomerOthersDetailsQ, CustomerAcDetailsQ, CustomerDetailsQ).CustomerAcDetailsQ has CustomerName, PhoneNumber, Address, Aircond and AcDetails. CustomerOthersDetailsQ has CustomerName, PhoneNumber, Address, Others, and WhatHasBeenDone.CustomerDetailsQ has CustomerID, CustomerName, PhoneNumber and Address
And 1 form with 3 subforms.
it's a search form, which would search for customers as we're typing in their name/phone number and it will show what has been done for the customer.
With this, I have created what the company wants, but now they want to add dates. Dates which would show when we have done something for a customer. Dates for Aircond and the Others stuff.
I've tried with what I know and it didn't work. tried searching it on youtube and google, but still couldn't find it.
how can I go about doing this?. I have tried having separate tables for each service, but it became a hassle when I wanted to create a new customer. . I hope I could some help, I could send pictures if someone needs them.
[1]: https://i.stack.imgur.com/mtrmC.png [The Customer search form] [1]: https://i.stack.imgur.com/A3Y9d.png [example of a customer that has ac installation] [1]: https://i.stack.imgur.com/dsGL5.png [example of a customer that has both ac and wiring done]
Acknowledging the question is too broad, here is some guidance. One of the nice things about Access is that each database is a single file. First protect your work by finding that file and make two copies. Make a backup and a play around version. Only mess with the play around version.
Your question indicates you are still learning Table Normalization and 1 to many relationships. Both of these topics are general to all databases, so you don't have to restrict yourself to just Access when looking for guides and Youtube videos.
Part of normalization is putting separate entities into their own tables. Also, in Access there is a big payoff for using the Relationship Tool, so here is a rather lame example of normalization:
Make sure to select the checkboxes when setting up relationships.
WhatHasbeenDone should also have WhatHasbeenDoneDate. I've wrapped AC and Other as Unit because later it will be easier than having two WhatHasBeenDone tables(AC)(Other).
Now imagine someone taking the customer request call. They just want to see a form to enter the customer details, request, unit-type, etc. They don't want to see those tables. Even with training entering data in the tables is error prone. The person fulfilling the request just wants to enter what they did and when. That's how you start to figure out what your final Data entry forms will look like.
Since we normalized the tables and used the relationships tool, the payoff is Access can give us an assortment of working starter forms. Select Each Table and then hit Create and then hit Form. Choose your Favorites and start playing around from there. While playing, keep in mind that Access will not let you add an item on the many side of a relationship unless there is an item on the 1 side.
For example I selected the customers table and hit create form:
Access uses a concept of form and subform based on separate but related tables. So, to get a form that shows what has been done for each customer I created a form for the What has been done table, and dragged it onto the customers form:
Unless an ID is also being used as a part number or something there is probably no reason for the person entering data to see it. So I removed the texboxes bound to ID's. Except for UnitTypeID, where I replaced the textbox with a combobox that displays the userfriendly UnitDescription. The ID's are still part of the form recordsources, Access is still adding new IDs and using those IDs to put the appropriate data in the right tables.
Oh, didn't we need dates (went back and added a date to the table, and adjusted the subform accordingly). Also changed the subform format from single record to continuous records to show multiple dates:
In conclusion and in my opinion your final forms will use VBA behind the scenes to insert data from the forms into the tables. This is because either you will want to rapidly insert multiple records or How the end users think about the data will not match the default forms and subforms approach Access depends upon to figure out how to insert the data. However, the default approach is fast and I always use it for version 1 of my Access Databases.
P.S. For simplicity I avoided including any Many to Many relationships
Wondering if someone could assist with the best way to handle storing "checked" items in a MSSQL database.
On my form, i have a list of fields (name, address ect) and then a listbox the user can check for e.g. favourite colors.
In my database I would have a table for user details (tbl_userdetails - [UserID, Address...]) and a table for colors (tbl_colors, [ColorID, ColorName, ColorCode]). I would also need a table for user colors (tbl_userColors - [userID, ColorID])Theses would be linked via a "userID"
Normally, to save the user details, I have a sql string "UPDATE tbl_userdetails SET... WHERE userID = #userID". What is the best way to save the changed checked items into the next table?
My thoughts are:
Delete all the colors for UserID in the tbl_userColors and then loop the checked items into a "INSERT" statment.
Loop though each item that exists in the list create a datatable and then "merge" the data (on match, insert. on not matched delete)
Any other thoughts? What is the best way to build the INSERT statment?
Cheers
The DELETE and INSERT strategy works well as long as nothing is tied to those records. If you ever have any tables that reference tbl_userColors on the "one" side of the relationship, then you will have headaches.
The MERGE strategy is decent, usually. One possibly unfortunate consequence would be that a MISSING record is the same as a FALSE record. For instance, you Have your list of colors, {red, green, blue}, and your users are making their selections. Six months later you get crazy and add orange. Now you have no idea who didn't select orange vs. those that simply weren't presented with orange as an option.
A third option is to place an Enabled BIT field on the tbl_userColors table. This allows you to determine if a user was presented with a color option and they declined it vs. if the user never saw a particular color option.
Speaking of Enabled BITs. Your tbl_colors table should really have an Enabled BIT as well - or some other mechanism of removing a color from the UI without removing its database record. You realize at some point you no longer want to offer blue to your users, but you also don't want to loose the historical data.
And a small aside: Your tables names are horrific. You should really consider dropping the Hungarian notation. I'm a big fan of camel-case table names: Users, Colors, and UserColors.
Simple really. When an item is checked it returns a boolean. Whenever you get ready to save to the database you just want to loop through the colors and if it is checked (AKA is check is true) then you add it to a list that you can later loop through to save all of the values.
I am working on a homework project where we design a website for a store, and I have been assigned the database. This is my first database attempt. I am using LibreOffice Base for the design, and cannot find any guides on how to make subtypes. For example, for every shirt in the inventory, there'd be a different group of colors it comes in and for every different color a list of individual sizes and how many of each size is in stock. However, I can't find aggregation anywhere in "Table Relations."
So I make a table for shirts with the base information (brand, price, etc), and then a separate table with just 2 columns (size and number of units in stock --- we're letting the possibility of multiple colors wait for now). I then make a form for the shirt with the base information and a subform with 2 columns: size and number available. Both of the forms are tables rather than labeled text boxes. However, the subform for shirt size does not maintain separate information for each row in the main form (ie the one with the base information for the shirts). How the heck do I do this?
Lastly, since this is my first crack at databases, I would not be at all surprised if I'm going at it all wrong, and if so would gladly appreciate a push in the right direction or a webpage explaining how to do this that I didn't find due to not entering the correct search terms.
You need to create linked fields in the master table. The shirt table has a primary key; refer to that in the subordinate table. Alternatively, create a primary key in the subordinate table and refer to it in the master table. Then in the subform --> properties, designate the appropriate link between the master and slave fields. The functionality is described in the LibreOffice Base handbook (p.105)
Working with cascading choices in the new(er) FMP seems to be a little weird. My intention is to create a bunch of drop-down lists / pop ups that rely on the previous choice. If a user clicks on a Customer drop-down, the next drop-down (address field) will ONLY have related data for that customer street address. Once you click the certain address, the other state, city, zip, etc fields will be automatically keyed in.
This is done by creating two tables (shipping, customer) along with a table occurrence of shipping and one unique value as a relationship in both the customer and shipping table...yeah. All of this is very doable, if not a little convoluted; however, I was wondering if there was a way to clean up these relationships? Sorry, calling all FileMaker pros out there, thanks!
I'm afraid the answer is no. Setting up cascaded value lists is rather tedious and, to my knowledge, there's no silver bullet. You're lucky to have just two levels :)
If I were going to take a stab at this, I'd try to build the next level of popup contents by deriving the necessary value list from the records of a related table. Since the selection of one value triggers the next popup, you're finding entries in a predefined database made of multiple tables where the values are all the possible dropdown list/popups. It's a cascade engineered through layouts, find and sort.
I'm creating a database with Access. This is just a test database, similar to my requirements, so I can get my skills up before creating one for work. I've created a database for a fictional school as this is a good playground and rich data (many students have many subjects have many teachers, etc).
Question 1
What is the difference, if any, between using a Lookup column and a many-to-many associate table?
Example: I have Tables 'Teacher' and 'Subject'. Many teachers have many subjects. I can, and have, created a table 'Teacher_Subject' and run queries with this.
I have then created a lookup column in teachers table with data from subjects. The lookup column seems to take the place of the teacher_subject table. (though the data on relationships is obviously duplicated between lookup table and teacher_subject and may vary). Which one is the 'better' option? Is there a snag with using lookup tables?
(I realize that this is a very 'general' question. Links to other resources and answers saying 'that depends...' are appreciated)
Question 2
What attracts me to lookup tables is the following: When creating a form for entering subjects for teachers, with lookup I can simply create checkboxes and click a subject for a teacher 'on' or 'off'. Each click on/off creates/removes a record in the lookup column (which replaces teacher_subject).
If I use a form from a query from teacher subject with teacher as main form and subject as subform I run into this problem: In the subform I can either select each subject that teacher has in a bombo box, i.e. click, scroll down, select, go to next row, click, scroll down, etc. (takes too long) OR I can create a list box listing all available subjects in each row but allowing me to select only one. (takes up too much space). Is it possible to have a click on/off list box for teacher_subject, creating/removing a record there with each click?
Note - I know zero SQL or VB. If the correct answer is "you need to know SQL for this" then that's cool. I just need to know.
Thanks!
Lookup columns in tables will cause you more stress than joy. Unless you need them for Sharepoint, they should be avoided. You may wish to read http://r937.com/relational.html and http://www.mvps.org/access/tencommandments.htm
I wouldn't use them. Your example is fine, but there are limitations. What do you do when you need to reference another field from the Subject table other than the name? How would you differentiate subjects that are only offered on a semester basis?
You have no way of getting a count of how many subjects each teacher is assigned without some ugly coding.
Another limitation, is when you start identifying who taught what courses during a given school year.
I'm kind of unclear on your second question, but it sounds to me like you need a subform with a dropdown list.
If you want to do the checkbox thing, it quickly becomes a lot more complicated. To me, you're starting from user interface and working backwards to structure, instead of going the other direction.
I hesitate to mention it, but in terms of full disclosure you should know that in A2007 and A2010, you have multi-value fields available, and they are presented with exactly the UI you describe. But they have many of the same problems as lookup fields, and are quite complex to work with in code. Behind the scenes, they are implemented with a standard many-to-many join table, but it's all hidden from you.
I wish MS would make the listbox with checkbox control that is used with MV fields available for all listboxes, but binding that to a many-to-many join table would be complex if the listbox control were not designed for that (with link child/link master properties, for instance).
I tried to come up with a way to offer you the UI feature you prefer from multi-value fields without actually using multi-value fields. That seems challenging to me.
The closest I could come up with is to load a disconnected recordset with your "List" choices and a check box field. Then create a form, or subform, based on that recordset which you present in datasheet view. It could look similar to a combo bound to a multi-value field. In the after update event of the checkbox field, you would need code to add or remove a record from the junction table as required.
However, I don't know if this is something you would care to tackle. Earlier you indicated a willingness to learn SQL if needed; the approach I'm suggesting would also require VBA. Maybe take a look at Danny Lesandrini's article, Create In-Memory ADO Recordsets, to see whether it is something you could use.
OTOH, maybe the most appropriate answer for you is to keep the multi-value fields and get on with the rest of your life. I'm stuck. But now that we know you are actually using multi-value fields, perhaps someone else will be able to offer you a more appropriate suggestion.