On Mon, 11 Aug 2014 16:48:48 +0400, Alex Peshkoff <peshk...@mail.ru>
wrote:
> On 08/09/14 16:40, Mark Rotteveel wrote:
>> Currently jaybird is handling isc_arg_interpreted the same as
>> isc_arg_string and assumes it is a message parameter for the message of
>> the previous error code.
>>
>> However I was just debugging the handling of the statusvector for the
>> new native client wrapper in Jaybird and I noticed - when trying to
>> connect to a non-existent database - that Firebird was returning a
>> statusvector with:
>>
>> isc_arg_gds, isc_io_error ("I/O error during "{0}" operation for file
>> "{1}""),
>> isc_arg_string, "CreateFile (open)",
>> isc_arg_string, (name of the database),
>> isc_arg_gds, isc_io_open_err ("Error while trying to open file"),
>> isc_arg_interpreted, "The system cannot find the file specified."
>> isc_arg_end
>>
>> As Jaybird was interpreting the last entry as a message parameter to
>> isc_io_open_err, and that doesn't have a parameter, it isn't showing
>> anything.
>>
>> Should I handle isc_arg_interpreted as an element on its own?
>
> isc_arg_interpreted is handled on its own - a string, just a string to
> type. It's not a parameter of other message.
Thanks. For now I have handled it by printing additional parameters if
there are more parameters than placeholders (which solves this problem, and
cases were I potentially use an older message format with less parameters
than provided by Firebird). I will see if I need to create a more formally
correct solution by treating isc_arg_interpreted as a separate element.
Mark
------------------------------------------------------------------------------
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
