Recently, I just added almost 20 fill ups over my cell phone, and data entry seems to be a nightmare, as I messed up an awful lot. Entirely my fault, and not the sites fault, but, maybe a new data check should be implemented to assist in ensuring that the dates entered make sense?
Also;
- On a side note, I don't remember if I was prompted on the mobile fill up form, but it MIGHT be prudent to have the fuelup_date as a full date & time field, or allow it to be included in the CSV as such, as with multiple fillups on that day (If I had the GA instead of a rental I would have filled up twice in a day) it'd allow for this sanity check above to be a bit more precise and cause one less false-alarm.
- I also `JUST` noticed that even though the CSV has the Metric heading values, the values themselves are still set for US. (KM and Liters are headings, 12.19 liters for a price of 3.79 doesn't make sense)
How I found the problem;
On Feb 7, 2009, I entered 18 fill ups, on my cell phone. I entered the fill ups out of order, meaning that I could have entered a fill up for January 2009 before I entered a fill up for Oct 2008, as I was sitting in the car waiting for the wife (And wanting to test out the new data plan on the cell.
)
I downloaded the CSV for all my fill ups tonight on the PC, and I noticed that when I sorted the data based on odometer, some of the dates I entered were out of order, and obviously didn't make any sense.
So my thought, as a very BASIC check in this sites submission code:
When submitting a new fill up from the past, take the odometer reading, compare it to what the previous date fill up was based on odometer reading only, and check to see if it makes sense against the user submitted fill up date.
As an example, if I were to have filled up at 118,495 on 11/13/08, and my next fill up was at 118,671, and I accidentally entered 08/08/08, it'd fail the data entry because I already have a fill up on 11/13/08 with a lower odometer reading.
My DB theory:
select odometer, fuelup_date from whatever_table_you_called_it where (odometer $_GET["fuelup_date"]) {
// Fail
echo "Houston, we have a problem."
exit
} else {
// Pass
echo "Houston, the Eagle has landed."
}
The problem that is going to come up is that if I erred previously with a date entry, I'm going to get stuck and will have to review the changes. What COULD be done is in the "Houston, we have a problem" section is give a simple, sorted (based on Odometer) table showing the odometer readings previous to, and after the user entered odometer reading, with the fill up dates, and then either allow to force the submission of the data so the user can go back and edit later on a PC, or, allow the user to make changes on the spot, if their cell browser allows it.
Of course, if I erred back on Feb 7, and entered a fill up on a date that hasn't happened yet (Which I did), the next time I fill up, and enter the new data for the fill up, I'd be confronted with the "Houston, we have a problem." error, but at least I'd know I'd have to fix something.
Now, to check my theory; If I didn't enter any data for a few months, then decide that I want to make an entry, I can still submit the new fill up (213,435 on the odometer, this fill up will happen Feb 28, 2010), with all said above, since my `last` fill up as far as your DB is concerned was at 118,495 on 11/13/08, the sanity check would pass, because my current odometer reading is bigger than the last fill up, AND the DB date is in the past.
Linear Mode
