Testing data in batches, entering in table directly or create a "pseudo" table?

[weeblebiker]

Testing data in batches, entering in table directly or create a "pseudo" table?

I know entering info into the table directly is a no-no, but that is what I want to do:
we do testing and are currently using a excel sheet.
We test 6 to 12 units at a time.
all the units are run through each test consecutively (info is entered by field column). then the next test is set up and all the units are run through the next test (and info is entered in the next field column).

all the test info for each unit is a record row.

currently we are hand writing a copy and entering in excel which is time consuming

I want to port the table into access because not saving/ overwriting/loosing data is too easy in excel. and ditch the hand written log book.

Is there a way to do data entry in a table format (like excel) in access?
entering data by field multiple times instead of entering data by record?

My users can't get directly to the tables in the back end. I have imported the excel tables into the back end and created linked tables in the front end.

How can I allow data to be entered by column besides directly into the linked table?
and/or
How do I set up a button to get to the linked table to do the data entry?

Thanks in advance!!!

 

[weeblebiker]

Re: Testing data in batches, entering in table directly or create a "pseudo" table?

no one?

 

[plog]

Re: Testing data in batches, entering in table directly or create a "pseudo" table?

I'll give it a go:

I want to port the table into access...

This project is going to require more than 1 table. Moving from Excel to Access is difficult for people because it requires a whole new way of thinking about data. So, while my ultimate answer is 'Yes, this can be done', the next phrase would be ', but achieving the input form you want will not be simple'.

I don't have a real clear understanding of the input form you want, but from the sounds of it so far, its not going to be a standard form bound to a table. Most likely to have a form like you described will require a lot of VBA on the backend to do the insertion of data into the right tables.

My advice is to build your tables--that's always the first step in any database--actually making forms is the last. So build your tables, post back the database along with a mockup of what you want your form to look like. With that I can help more.

 

[weeblebiker]

Re: Testing data in batches, entering in table directly or create a "pseudo" table?

The root issue is currently using only 1 sensor and testing a unit repeatedly instead of multiple sensors and testing a unit once. This involves a lot of time and moving back and forth by the testing tech.

The current methodology of testing is a relic from when our volume was 25% of current volume.

I'm pushing to get more sensors and testing unit once to get all the sensor data at once which will eliminate the access record conundrum, along with decreasing the testing time by 80% ish.

explaining an issue in writing is very useful in determining the root causes. One can put it out there, let some time pass and come back to it subjectively.

Thanks!