Narrative:

During initial cockpit setup; attempts by the crew to load ogg as destination airport in the FMC were unsuccessful and generated repeated 'not in database' messages. Neither ogg or lih airport data was available in the FMC. Maintenance was summoned and dispatch advised. Maintenance personnel advised us that a new FMC data base had been loaded that morning; and that they would attempt to remove and replace it with the 'old' database. Maintenance performed various resets; diagnostics; etc. But was unable to reinstall the old database. In concert with dispatch; maintenance generated a MEL deferral. The operations placard for this item imposed two 'flight planning' restrictions; but no operational; or flight restrictions or ancillary notes. Per the MEL verbiage; dispatch was tasked to verify navigation fixes; status; etc. And the flight crew was tasked with using current charts to verify navigation fixes; and to verify that approach navigation radios were properly tuned. Ogg ILS runway 02 localizer was tuned manually on the ground just to make sure that would work. Based on this info; VFR weather at ogg; and added fuel; the decision was made that the flight could be safely operated. When maintenance had completed their activities; the flight crew re-commenced their sops; loading and verify the routing; etc. Reference was made to the flight manual - destination not in database procedure. During cockpit setup the center VHF radio was observed to be out of 'data' mode and attempts to return it to data mode by normal methodology were unsuccessful. Normal function was regained by repeating the comm-manager-master reset; and the anomaly was attributed to maintenance's various activities. The flight eventually departed in IFR conditions and takeoff and climb were normal. Prior to initiating cpdlc logon; it was observed that FMC time estimates were accurate except for the last fix on the route which appeared as a much earlier time - about thirty minutes later than current clock time - and well before any of the other fixes. Fuel estimates appeared accurate. Proper loading of the route was again re-verified. The last fix was deleted; which then transferred the time anomaly to the preceding fix. The last fix was reloaded; and the erroneous time was again associated with it. Attempts to logon to cpdlc were unsuccessful; and it was observed that the aircraft specific info had dropped from the ATC login page. The aircraft north number; company; and other info was reloaded; and cpdlc logon was then successful. After some time at cruise; the EICAS 'no landing altitude' message appeared. The QRH was consulted; and a manual landing altitude of zero was set. The final fix time anomaly persisted; until hnl was placed in the FMC as destination; at which point the estimate became reasonable. Enroute; a satcom call was placed with dispatch to consult with maintenance regarding any other surprises that might be in store; particularly with regards to egpws function on arrival and the dearth of information in the MEL operations placard. Dispatch was reminded that we would not be able to execute a back course localizer approach; or any terminal procedure dependent on use of LNAV. With the actual and forecast weather at ogg this was a non issue. Maintenance advised that he would query the MEL operations engineer regarding our questions. Eventually maintenance sent us a message apologizing that the operations engineer was 'not in' today so it was unlikely that any info would be forthcoming. Flight proceeded to maui uneventfully; until right pack failed to backup mode during descent. Visual approach and landing were normal. On arrival at the gate; engines were shutdown. Checklist was completed; but the 'fuel control switches' item would not go green. Engines were verified shutdown and fuel flow zero. After checklist completion; numerous EICAS messages began to appear; without apparent cause or obvious defect. An attempt was made to send info to maintenance regarding these; but themessage terminated in midstream and could not be re-initiated. At this point with about twenty minutes remaining before departure of our scheduled deadhead leg; we packed up and departed; advising the waiting first officer for the outbound flight of all the happy news. I do not believe that the operations placard info associated with this MEL item is adequate or gives sufficient guidance. It does not address the fact that there is a flight manual procedure for destination airport not in database. It does not indicate that the 'no land altitude' EICAS message will be forthcoming. It does not address the numerous flight planning and operational flight restrictions imposed by having to build and fly a 'raw data' approach procedure. It does not address the lack of capability to execute a back course localizer approach; RNAV procedure; or any operation such as STAR or SID in the terminal area for which LNAV is required for steering. None of the terminal procedure fixes were present in the database for maui with the exception of the missed approach holding fix; which is apparently an airways fix. Other database defects that may have existed were unknown to us; so I would have to say that MEL guidance is seriously deficient. I would never accept an airplane with a known database deficiency that precluded normal FMC ops in the terminal area unless the weather was extreme VFR; which in the case of maui today; it fortunately was. The non-availability of maintenance engineering support is also a large negative. It would also be beneficial to know when maintenance has loaded a new FMC database; so that flight crews could be on the lookout for data problems or defects more subtle than ours. Such activity is currently not obvious. And what is the story with a vendor furnishing defective databases. Perhaps we are pushing too hard and trying to do too much on the 'cheap?' finally; I would have to question the operational wisdom and rational of taking an aircraft with a known defective database away from a maintenance station to an isolated non-maintenance station and inflicting it on another crew.

Google
 

Original NASA ASRS Text

Title: B777 Captain discovers during preflight that their destination is not in the database. Maintenance is unable to correct the problem and the flight is dispatched with a maintenance deferral. The Crew uses 'Destination Not In DataBase' procedures but encounters many problems enroute and after landing; both related to the deferral and unrelated.

Narrative: During initial cockpit setup; attempts by the crew to load OGG as destination airport in the FMC were unsuccessful and generated repeated 'NOT IN DATABASE' messages. Neither OGG or LIH airport data was available in the FMC. Maintenance was summoned and Dispatch advised. Maintenance personnel advised us that a new FMC data base had been loaded that morning; and that they would attempt to remove and replace it with the 'old' database. Maintenance performed various resets; diagnostics; etc. but was unable to reinstall the old database. In concert with Dispatch; Maintenance generated a MEL Deferral. The OPS placard for this item imposed two 'flight planning' restrictions; but NO OPERATIONAL; OR FLIGHT RESTRICTIONS or ancillary notes. Per the MEL verbiage; Dispatch was tasked to verify NAV fixes; status; etc. and the Flight Crew was tasked with using current charts to verify NAV fixes; and to verify that Approach NAV radios were properly tuned. OGG ILS Runway 02 Localizer was tuned manually on the ground just to make sure that would work. Based on this info; VFR weather at OGG; and added fuel; the decision was made that the flight could be safely operated. When Maintenance had completed their activities; the Flight Crew re-commenced their SOPs; loading and verify the routing; etc. Reference was made to the flight manual - destination not in database procedure. During cockpit setup the center VHF radio was observed to be out of 'DATA' mode and attempts to return it to DATA mode by normal methodology were unsuccessful. Normal function was regained by repeating the Comm-Manager-Master reset; and the anomaly was attributed to Maintenance's various activities. The flight eventually departed in IFR conditions and takeoff and climb were normal. Prior to initiating CPDLC logon; it was observed that FMC time estimates were accurate except for the last fix on the route which appeared as a much earlier time - about thirty minutes later than current clock time - and well before any of the other fixes. Fuel estimates appeared accurate. Proper loading of the route was again re-verified. The last fix was deleted; which then transferred the time anomaly to the preceding fix. The last fix was reloaded; and the erroneous time was again associated with it. Attempts to logon to CPDLC were unsuccessful; and it was observed that the aircraft specific info had dropped from the ATC Login page. The aircraft N number; company; and other info was reloaded; and CPDLC logon was then successful. After some time at cruise; the EICAS 'NO LANDING ALTITUDE' message appeared. The QRH was consulted; and a manual landing altitude of zero was set. The final fix time anomaly persisted; until HNL was placed in the FMC as destination; at which point the estimate became reasonable. Enroute; a SATCOM call was placed with Dispatch to consult with Maintenance regarding any other surprises that might be in store; particularly with regards to EGPWS function on arrival and the dearth of information in the MEL OPS placard. Dispatch was reminded that we would not be able to execute a Back Course Localizer approach; or any terminal procedure dependent on use of LNAV. With the actual and forecast weather at OGG this was a non issue. Maintenance advised that he would query the MEL OPS Engineer regarding our questions. Eventually Maintenance sent us a message apologizing that the OPS Engineer was 'not in' today so it was unlikely that any info would be forthcoming. Flight proceeded to Maui uneventfully; until right pack failed to backup mode during descent. Visual approach and landing were normal. On arrival at the gate; engines were shutdown. Checklist was completed; but the 'Fuel Control Switches' item would not go green. Engines were verified shutdown and fuel flow zero. After checklist completion; numerous EICAS messages began to appear; without apparent cause or obvious defect. An attempt was made to send info to Maintenance regarding these; but themessage terminated in midstream and could not be re-initiated. At this point with about twenty minutes remaining before departure of our scheduled deadhead leg; we packed up and departed; advising the waiting First Officer for the outbound flight of all the happy news. I do not believe that the OPS placard info associated with this MEL item is adequate or gives sufficient guidance. It does not address the fact that there is a Flight Manual Procedure for destination airport not in database. It does not indicate that the 'No Land Altitude' EICAS message will be forthcoming. It does not address the numerous flight planning and OPERATIONAL FLIGHT RESTRICTIONS imposed by having to build and fly a 'raw data' approach procedure. It does not address the lack of capability to execute a Back Course Localizer Approach; RNAV procedure; or any operation such as STAR or SID in the terminal area for which LNAV is required for steering. None of the terminal procedure fixes were present in the database for Maui with the exception of the missed approach holding fix; which is apparently an airways fix. Other database defects that may have existed were unknown to us; so I would have to say that MEL guidance is seriously deficient. I would never accept an airplane with a known database deficiency that precluded normal FMC ops in the terminal area unless the weather was extreme VFR; which in the case of Maui today; it fortunately was. The non-availability of Maintenance Engineering support is also a large negative. It would also be beneficial to know when Maintenance has loaded a new FMC database; so that Flight Crews could be on the lookout for data problems or defects more subtle than ours. Such activity is currently not obvious. AND WHAT IS THE STORY WITH A VENDOR FURNISHING DEFECTIVE DATABASES. Perhaps we are pushing too hard and trying to do too much on the 'cheap?' Finally; I would have to question the operational wisdom and rational of taking an aircraft with a known defective database away from a Maintenance Station to an isolated Non-Maintenance Station and inflicting it on another Crew.

Data retrieved from NASA's ASRS site as of April 2012 and automatically converted to unabbreviated mixed upper/lowercase text. This report is for informational purposes with no guarantee of accuracy. See NASA's ASRS site for official report.