That depends on your definition of "last record". A script can have three set field steps as easily as it can have one so tapping a button that runs a script to enter the data should be quite simple to set up.
"Last Record" being the record immediately before the one you're currently on. I know the default Last Record thing goes off of the last record you viewed, which isn't necessarily the record before the one you're working on.
So, I need to figure out how to do a script that says "When I click this button, fill out the fields YEAR, MONTH and DAY with the same values from the record before this one".
edit: Assume I'm a total newbie at this program and don't know all the easy and/or correct ways to do this stuff (because I am and I don't ;) )
edit2: I figured it out. Using the script manager, I made a new script with multiple Set Field lines for YEAR, MONTH and DAY which each used the function GetNthRecord(FORM::FIELD;Get(RecordNumber)-1)
This seems to work for my purposes, unless you know of a better way to do it
Please be firmly aware that the "record before this one" is dependent on your sort order...if you sort differently, you may get some odd and undesired results.
That's a good note to keep in mind. Ideally, my users shouldn't be sorting the data themselves anyway - they should just be entering the number of whatever species of grasshopper they find, and then move on to the next record. I will be left to do all the major sorting, formatting and exporting of this data into CSVs which we host on our server once they've completed their data entry.
I suppose that raises a good point, though - how can I keep my users from messing with how the data is sorted? Ideally, it'll stay sorted by the order in which they entered each record. The crux, though, will be that I still want them to have the ability to go back and forth between the records, modify the records in case they made a mistake, or delete a record entirely if it's necessary.
Since your records are in a portal, the order of the records in the portal is fixed unless you go to considerable lengths to provide an option for changing that order in the portal. So Ninja's concern isn't a major issue in this context.
I'd take a nother look at your three fields for three parts of the same date. Given how the iOS date picker works, you might find it works pretty well to just enter a single date and then, if you need the separate fields, use calculations to extract the needed month, day and year values. That allows you to take advantage of the built in date validations to keep users from entering an invalid date such as Feb 30 or some such...