> > 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.
True, but what device? What path? The current message is 99% useless without the file path/name. It effectively reads as: "You have a problem... somewhere. Go figure it out." > But maybe Bjoern's point has been missed: why should a temp file be > needed to restore deactivated indexes? I don't think that was his point, but will see what he says. > 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? Huh? ------------------------------------------------------------------------------ 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
