Re: Need an error trap for Date/Milage

[Allen Browne]

"Tony Toews [MVP]" <ttoews@teluspl anet.netreplied in message
news:g075f4pkmg 4uc5hk0ohdjfcae ph6ff963f@4ax.c om...

>
If you have any such you will need to also consider hours accumulated
which,
for example, bulldozers do.

Tony, I did one of these recently, and asked the client, "Could there ever
be a case where you need to store both (i.e. hours of operation and miles
travelled)? The answer was no, so we just called the field MeterReading
(Double), and added a MeterTypeID field to the VehicleType table.

The real fun comes when you have to project anticipated servicing dates
based on current usage trends, where service is required every xx
hours/miles or xx months/days whichever comes first, particularly if
servicing is component-based (some components are different to others)
and/or tiered (e.g. the A service includes all requirements of the B
service.)

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

[Tony Toews [MVP]]

Re: Need an error trap for Date/Milage

"Allen Browne" <AllenBrowne@Se eSig.Invalidwro te:

>If you have any such you will need to also consider hours accumulated
>which,
>for example, bulldozers do.

>
>Tony, I did one of these recently, and asked the client, "Could there ever
>be a case where you need to store both (i.e. hours of operation and miles
>travelled)? The answer was no, so we just called the field MeterReading
>(Double), and added a MeterTypeID field to the VehicleType table.

Double? That's a big extravagent. <smile>

However there can be case where a truck, that spends both a great deal of time
driving and a great deal of time providing hydraulic or pumping power where the next
service depends on either miles/kms or hours. A bad example would be a firetruck
although they typically don't drive much and spend a lot of time on scene pumping
water. A good example might be a underground boring machine on the back of a truck
which drives many hundreds of kms to it's next stop but spends hours providing
hydraulics and power to the boring machine.

Then there are situations where there's another motor on the same machine. For
example a large truck or front end loader mounted snowblower with one motore for the
drive axles and another motore for the snow blower. But for those few situations
the user just creates two units. Especially if it's a snow blower on a front end
loader which could be mounted on different loaders from year to year.

>The real fun comes when you have to project anticipated servicing dates
>based on current usage trends, where service is required every xx
>hours/miles or xx months/days whichever comes first, particularly if
>servicing is component-based (some components are different to others)
>and/or tiered (e.g. the A service includes all requirements of the B
>service.)

Oh yes. And I'm not going to get into projecting anticipated dates for now. It can
very too much up here what with winter being a major factor. The bulldozers have
been running 12 hours a day since May and will be shutting down in another few or
four weeks in this area. At peak times the service intervals may only be 10 to 20
days apart and then you get rained out for a week.

I will be giving them the ability to
1) easily locate the units for they which haven't received a odometer or hour meter
reading in some time
2) print a report by unit type with underlines so a gofer (person who "goes for" this
and that.) can go around to the units and write down the readings and a simple means
of entering that data.
3) reminders when they are approaching or have exceeded the various service intervals
such as, in gasoline motors, the timing chan.

One amusing anecdote as the the New York ambulance doesn't bother scheduling major
maintenance on their ambulances. They are, on average, in a major accident every 18
months and written off.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at

http://www.granite.ab.ca/accsmstr.htm

Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

[Tony Toews [MVP]]

Re: Need an error trap for Date/Milage

"Tony Toews [MVP]" <ttoews@teluspl anet.netwrote:

>so we just called the field MeterReading

>>(Double), and added a MeterTypeID field to the VehicleType table.

>
>Double? That's a big extravagent. <smile>

Actually maybe not. While unlikely a Single would only take you up to 3,402,823 kms
so that's certainly possible.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at

http://www.granite.ab.ca/accsmstr.htm

Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

[Allen Browne]

Re: Need an error trap for Date/Milage

I rarely use single anyway. Even for calculating fractions of an hour, the
inaccuracies are cumulative.

As per your other reply, the scenarios are always fun.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Tony Toews [MVP]" <ttoews@teluspl anet.netwrote in message
news:0eh5f4dgdf 70ktvjm17i9qbmf rlj589u8s@4ax.c om...

"Tony Toews [MVP]" <ttoews@teluspl anet.netwrote:
>

>>so we just called the field MeterReading

>>>(Double), and added a MeterTypeID field to the VehicleType table.

>>
>>Double? That's a big extravagent. <smile>

>
Actually maybe not. While unlikely a Single would only take you up to
3,402,823 kms
so that's certainly possible.
>
Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at

http://www.granite.ab.ca/accsmstr.htm

Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/