At 07:57 AM 5/10/2012, Vlad Khorsun wrote: >> Why does Firebird return such a low level OS-dependent(?) error message >> instead of returning a Firebird-specific message that explains what went >> wrong (eg creating temporary files), instead of why it failed (the >> low-level error message)? > >- because it was written this way many years ago (before it became Firebird) >- because without original lowest-level error it is impossible to find a >reason for failure >- because in most cases it is obvious what Firebird did at failure moment > > I agree that sometime more context from intermediate levels could help to > better >understand what happens. For example, when transliterate error happens it is >good >to know assignment destination (field or variable) name. I'm not sure it is >easy to >implement. But in the case of "CreateFile failed" when index is built... - i >see nothing >to add here, it is clear enough as for me...
The OS message in this case should be helpful enough: "gbak: ERROR: Das Gerät ist nicht bereit. (Device is not ready) suggests it's a problem the administrator has to deal with as Firebird doesn't control OS level stuff like file permissions, mounting devices, making sufficient temp space available, et al. But maybe Bjoern's point has been missed: why should a temp file be needed to restore deactivated indexes? Could that be a bug whereby, at the point where gbak is creating the deferred indexes, it has lost the significance of the original "inactive" flag? Helen ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
