In case a330pilotcanada's post wasn't sufficiently clear...or, in case I've missed the boat altogether, we've now seen the second such incident in as many weeks.

AvHerald's report of the latest - with reference to the first: Incident: Air Canada E170 at New York on Dec 9th 2012, descended below safe altitude

Perhaps the cause of the second is written on the bottom line of the first:

gwillie;

Re, Internal Safety Investigations done by the airline are usually effective and is the way SMS works in Canada and, I suspect, the U.S. The regulator has oversight responsibilities of course, (assuming the necessary resources are in place...) but in this kind of an incident an internal investigation is reasonable and warranted. Sometimes FOQA data helps in such investigations depending upon the agreements with pilots' associations. Regardless, the airline's safety policy and culture is non-punitive so getting to the bottom of why this happened is only a matter of information-gathering and time.

And another, more serious problem: the SOPs did not catch that database error.

Also, no company-checking of database prior to use?

Good Evening Captain Bloggs:

Although retired the S.O.P. is to check that the data base is current ie 01-12-2012 to 31-12-2012. If not select the correct data base if roll over has happened.
In addition in the pre-descent check protocol not only calls for the approach briefing but confirmation that the data matches the approach plate, notams etc
I had a chuckle that previous poster brought up the old saw about metric visibility versus Imperial measurement. Short answer the approach plate visibility limits has to match what is on the ATIS reported visibility etc.
As I stated earlier wait for the investigation to be complete and someone will attach the official finding in a post as opposed to conjecture but I digress

What I was alluding to was procedures/techniques to spot when the aircraft, which is following the box, is going off the rails ie diving below the required profile between waypoints.

Re the company checking, I understand that some check the database before flight use using a checking program.

Is it conceivable that this sort of database error (if it is the problem) could occur on a RNP-AR/SAAAR approach where there is no way of checking the profile altitude/distance down the approach apart from perhaps total track miles to run (if it is displayed somewhere?).

I highly doubt it. There is a lot of double-checking going on with the FMS, GPS, eGPWS etc. behind the screen and any discrepancy should trigger a warning in the scratchpad resulting in an evasive maneuver. Not sure if there is any protection against a corrupt database. There might have been recent changes I am unaware of, since I have changed equipment earlier this year.

The VNAV function seems a little buggy: One problem my company encountered with the E190 was with company RNV-F visual approaches into LGA runway 31 and DCA RNV-F 19. Half the time the VNAV would not capture. I heard from some check airmen that Honeywell tries to blame it on Embraer and vice-versa, in other words, the same blame game software companies play.

I learned quickly to not rely on VNAV on this aircraft.

G/S Capture
 

Truth is the G/S was 'captured from above, all the restrictions & heights were checked on the computer against the Jepp Chart, ( as per SOP)......FYI, there has been a software glitch on the Embryo in this regard for awhile now. Once on the path, the A/C does not respect the crossing restrictions.....

- that seems bizarre! Surely the 'path' is constructed in the FMS from the crossing restrictions as 'hard points' so how can it not 'respect' them?