I'm looking to bulk input data from google forms. This involves 2 sections:
Initial Conditions
Observations
Everyone who wants to input data will be inputting 1 set of initial conditions, followed by somewhere between 5 and 20 (maybe more?) observations of multiple variables:
Name
Date
Color
Quantity
Type
The problem is that I don't want to have to make people re-enter the initial conditions each time they submit a form.
Ideally they would be able to select a response after adding one observation:
Add another observation
Conclude session
The thing I don't know how to do: Add another observation would open a new blank observations page.
Anyone have any ideas about how to make the appropriate form?
Related
I have a question regarding a data entry form for project pricing estimates I am currently building.
To give you some context: The form will be used to enter data and complete calculations. It will replace an excel spreadsheet comprising of 59 columns, 1-15 rows (it varies by requirements) per project estimate. Average number of projects is 50-60 per year saved in respective customer folders. If there is an update to the estimate, a new version of the spreadsheet is created and saved in the respective customer folder. Hence, in certain scenarios, there are can be up to 10 versions saved per customer per project.
I am seeking to create a form-table combination for each of the customers: hence 10-15 forms with the same structure. Currently, I am only creating one form and table combination as a test. The table designed to replace the spreadsheet will use a total of 30 auto number foreign keys to store information. To be user friendly, I am using combo boxes in my form, where the user types in text but is stored as a foreign key in the table.
On top of this, I need to include calculations. For example, if the user selects certain options from my combo boxes, this will result in a calculated answer in an adjoining form field. Part of the calculated answer will use data in a linked table from another access database. Based on the options selected in the form combo boxes, the database will scan specific columns in the linked table to find matching entries to the selected combo box options. If a match exists, a price is extracted from that linked table. So say the combo box options selected are origin Miami and destination Salt Lake City, the database will scan for those 2 entries in the linked table. If that entry combination is found in the linked table, this price is to be used in the calculation. This price will then be multiplied by two other components entered by the user in the form, resulting in the calculated answer.
My questions:
Regarding the calculation example I gave above, can the above scenario be realistically accomplished in Microsoft Access? If so I am assuming I have to use VBA and/or Macros to do so?
a. If so, is it suitable to use my data entry form to complete it? Or is there an alternate way to achieve this result?
Will 30 combo boxes combined with such calculations have a significant impact on the speed of my form and database, especially as more data is added to the form and given that 10-15 forms will use the same structure? I have thus far included half of the combo boxes in 1 form, completed 1 test entry and I find that occasionally there is a slight lag when opening the form.
a. If it will impact my form's performance, what are my options/other form controls I can use to minimize lag and maximize speed?
Many thanks in advance!
As an amateur coder for some years I have generally used sub forms when dealing with linked tables to make the transfer of ID field from primary to sub nice and simple...
However in my latest project the main form is a continuous form with a list of delivery runs (Date, RunName, RunCompleted) etc... Linked to this primary table is a delivery list containing (SKU of product, Qty etc...). I use a simple Relationship between the two tables.
Now, On the main (RUNS) form at the end of each row is a button that opens the DELIVERIES form and displays all records with matching RUNID
This is fine for displaying pre-existing data but when I want to add new records I have been using the following code attached to the OnCurrent event:
Me.RunID = DLookup("[RunID]", "tbl_BCCRuns", "RunID = " & Forms![frm_BCC_Runs_list]![RunID])
I have also used:
Forms![frm_BCC_Deliveries].Controls![RunID] = Forms![tbl_BCCRuns].Controls![RunID]
(Note: above done from memory and exact code may be incorrect but that's not the problem at hand)
Now... Both these options give me what I need however...
I find that as I am working on the database, or if you open certain forms in the right order (a bug I need to identify and fix clearly) you can open the DELIVERIES form without the filter (to view all deliveries for arguments sake) and the top entry (usually the oldest record) suddenly adopts the RUNID of the selected record back in the main form.
Now, my question is this, and the answer may be a simple "no" and that's fine, I'll move on...
Is there a better way, a way I am not familiar with or just don't know about due to my inconsistent Access progress, to transfer ID's to a form without risking contamination from improper use? Or do I just have to bite the bullet and make sure that there is just no possible way for that to happen?
In effort to alleviate the issue, I have created a Display Only form for viewing the deliveries but there are still times when I need to access the live historical data to modify other fields without wanting to modify the RUNID.
Any pointers greatly appreciated...
Since you only want to pull the RunID if the form is on a new record row, do a check to verify this is a new record.
If Me.NewRecord Then
Me.RunID = DLookup("[RunID]", "tbl_BCCRuns", "RunID = " & Forms![frm_BCC_Runs_list]![RunID])
End If
Could also consider a technique to synchronize parent and child forms when both are subforms on a main form (the main form does not have to be bound) https://www.fmsinc.com/MicrosoftAccess/Forms/Synchronize/LinkedSubforms.asp
I have created a form in which students have to tell if they've formed a group of 4, 5 or 6 members and correspondingly fill out the email id's of all members in the group.
Right now, all the responses land in a single document, like this
I want that depending on the group size, 3 different spreadsheets be created. To say, All group of 4 responses in 1 spreadsheet, all group of 5 in one spreadsheet and all group of 6 responses in one spreadsheet. So 3 spreadsheets for the 3 group options.
I was going through the web and I see its possible via App scripts but I couldnt figure out how. Any leads on this?
no need to use script for this which is not trivial to do and handle all possible errors.
instead simply use a combination of importRange and filter/query to the other spreadsheets from the master responses.
by using spreadsheet formulas your spreadsheets will always update correctly and instantly.
The easiest way would be to use an installable trigger on the form which is called on form submission. Rather than using the default functionality of adding all responses to a "Form Responses" sheet, your script would then take the raw form data and add it to the appropriate sheet based on the group size.
I'm using Access 2010 and I would like to create a form where useres can enter data much like they can in an Excel format. The users need to enter a date when a step is complete for a specific unit.
In Excel the units run aross the top row, the steps run down the left column. In the cell where the unit and step meet, you put a date when it is done. In Access it is much harder to create a form that looks like this (at least it has been for me so far). I tried to use a crosstab query, but you cannot enter information into a crosstab query. I can do a massive form listing every combination of units and steps, but there are over 50 units and each one has 63 steps. I don't want users to have to look through a form with over 3,000 lines in it just to enter a date completed.
This definitely feels like something we should be using a database for instead of an Excel spreadsheet. I have the format for the back end tables to hold the data. My problem is how to create a form that is easy for the user to enter the dates.
I think you have three options. First, you could build the form from scratch, which you've already admitted would suck. And it would take a lot of VBA to get the data in the right place. Second, you could automate Excel - it's the same as the first method but you don't have to build the form. You would populate an Excel spreadsheet and write the changes back to the database. This is not a trivial task and I don't recommend it.
The third option is to throw away the idea that you want to do this in a grid. You've probably been doing it in Excel and to the extent that you replicate that, your users will be happy and comfortable. Moving to a database gives you benefits, but there are costs. This is one of the costs.
So create a form with a dropdown containing all of the units. When a unit is selected, populate a subform (datasheet view) listing all of the procedures and dates. The user can then select the unit, and fill in the date next to whichever procedures he wants. Then he can select another unit and do the same thing. If you set it up right, your data will flow to the tables automatically and you'll get all the benefits of data validation, input masks, relationships, and whatever else you're using at the table level.
I know that's not what you were looking for, but I think it's the best way forward.
Say for example I am getting a range of integers from a user:
Generate between nnn and nnn widgets.
Yes, most users will ensure that the first number is equal to or less than the second number:
Generate between 3 and 7 widgets.
But then there's that user, who wants to enter this data "back to front";
Generate between 7 and 3 widgets.
Do you quietly switch the fields around when the user clicks OK/Apply so, in the example above, you change the range of 7 to 3 back to 3 to 7 in the GUI? This might not be so practical on a web form where the user enters some data and then submits the form never to see it again but I'm thinking more in terms of a desktop application's settings page where the user's input is saved and subsequently viewed and edited again by the user.
Is it more important to try and educate users to enter a range that "makes sense" via error/alert messages, or quietly cajole their entries into the shape an application is expecting?
I suspect the "cajoling option" is more preferable, but could this "hey the program messed with my data!" approach be a problem for users?
I am currently writing an application that has a handful of these user-configurable ranges so I'm very interested to follow the general consensus of the SO experts.
If the user enters data incorrectly you shouldn't assume a particular pattern of error and automatically correct it. Either report the error to the user and ask them to correct it or suggest a correction that they can approve. In your example, what if the user intended to type 7 and 13 but simply mistyped. If you changed it to 3 and 7 you've entered incorrect data without the user's knowledge. I'd probably do the simple thing and use a visual alert when incorrect data is entered (but before it's actually submitted) and refuse to accept incorrect data, returning an error if it is submitted incorrectly.