Opening Access Form to Last Record in Table

[davegri]

Views: 3 Size: 29.5 KB">Mer-davegri-v01.zip

As I suggested, and it's easy to do. Uses embedded macro created by wizard, your existing standalone macro not needed.

[Merrill B.]

I do that but you need to reopen the form out of the macro and it works but as an extra manual step.

[Merrill B.]

There are two tables involved and one form and information is transferred from one table to another then to the form where data entry is completed using a written document that has information on it to be entered. I also note that one table is a control table that feeds basic information to another before the form (representing both tables) is complete. Also it is easier to scan a table in datasheet view then to scroll 200 files in form view for one that meets a specific criteria. A query would be very complicated to construct in this case as there are forty fields involved and multiple criteria to determine if a record is to be included.

[Merrill B.]

Thank-you for your general comments. There are two tables involved and one form and information is transferred from one table to another then to the form where data entry is completed using a written document that has information on it to be entered. I also note that one table is a control table that feeds basic information to another before the form (representing both tables) is complete. Also it is easier to scan a table in datasheet view then to scroll 200 files in form view for one that meets a specific criteria. A query would be very complicated to construct in this case as there are forty fields involved and multiple criteria to determine if a record is to be included. Forms definitely work with one record or portion thereof at a time but tables present the non-academic opportunity to view data in a datasheet which to the masses still has value.

[davegri]

Thank-you for your general comments. There are two tables involved and one form and information is transferred from one table to another then to the form where data entry is completed using a written document that has information on it to be entered. I also note that one table is a control table that feeds basic information to another before the form (representing both tables) is complete. Also it is easier to scan a table in datasheet view then to scroll 200 files in form view for one that meets a specific criteria. A query would be very complicated to construct in this case as there are forty fields involved and multiple criteria to determine if a record is to be included. Forms definitely work with one record or portion thereof at a time but tables present the non-academic opportunity to view data in a datasheet which to the masses still has value.

That's colossal requirements creep far beyond your original request. Did you really expect a suitable proposal based on that original limited disclosure? I almost think this is some kind of prank.

[Welshgasman]

Plus there is such a thing as a datasheet form.
Entering data directly into a table means little validation.
He'll!, even I do not enter data to a table directly. Even for the dbs for my personal dbs.

[señor_sriracha]

Thanks for analytical response and clear response. I note that the macro instructs the table to open first at which point there is an edit (addition of a record) "before" the form opens. If correct then it is not simultaneous occurence and the instruction to open the form (as the lattter instruction), should have the form reflect the updated table. Do you agree and if so, can you offer a tested solution that demonstrates the form showing the same number of records as the table without refeshing manuallyl?

Macros just plow through their code one step after the next, there is no feedback to indicate that one step is completed and it's OK to move to the next. Most of the time this is fine as the steps don't take long. For long operations, especially ones that require user input, the macro just moves to the next step as soon as it finishes starting the current step (not the same thing as waiting for the step to finish). It has no way to know if the step was completed. VBA doesn't really have an await operator either, but there are a few workarounds.

In this case you would probably be better served by doing all of your data entry on the form and forget opening the table. Set the form for Data Entry or add some VBA when the form loads that moves to a new record. You could even convert the form to a datasheet or split form if you prefer entering data in the datasheet like you were in the table.

[Merrill B.]

I consider my Thread closed so thanks to all the participants who responded positively to my small access problem related to the opening of table and forms within a macro context. I have simply developed and added on a second macro and assigned a key to run it. I had condensed the problem in my threads to the main issue. And yes forms are useful but they owe their existence to properly constructed tables. Sometimes there is elegance in simplicity.

[davegri]

I consider my Thread closed so thanks to all the participants who responded positively to my small access problem related to the opening of table and forms within a macro context. I have simply developed and added on a second macro and assigned a key to run it. I had condensed the problem in my threads to the main issue. And yes forms are useful but they owe their existence to properly constructed tables. Sometimes there is elegance in simplicity.

Thanks a lot for ignoring solid advice and wasting all our time. You are on my ignore list.