>>> 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.
Looks like famous "printer is out of paper" Windows error :) But we can't
control
OS errors, all we can do - is to catch and report it. If we did it wrong i need
reproducible
test case to be able to investigate it.
> True, but what device? What path?
DBA should know where temporary files is placed. If my memory serves me
well, this
issue was discussed few years ago and it was decided to not include full file
names in
such error messages from the security POV...
> The current message is 99% useless without the file path/name. It
> effectively reads as:
>
> "You have a problem... somewhere. Go figure it out."
This particular case is clear. Other cases could be less clear, agree.
Regards,
Vlad
------------------------------------------------------------------------------
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
