Thank you.
I will provide one more test for firebird 2.5.2. I have a corrupted base, I
will see what gfix says after running it. I think that it should return 1 as an
error code. Or atleast error code <> 0.
Ok, I've checked this with gfix version: gfix version WI-V2.5.1.26351 Firebird
2.5
According to stackoverflow: I can test the error result of application like
this:
http://stackoverflow.com/questions/3452046/get-error-code-from-within-a-batch-file
So I did a batch file and executed it:
C:\Pro
--- In firebird-support@yahoogroups.com, "un_spoken" wrote:
>
> I will provide one more test for firebird 2.5.2. I have a corrupted base, I
> will see what gfix says after running it. I think that it should return 1 as
> an error code. Or atleast error code <> 0.
>
You think wrong.
Comma
> You think wrong.
>
> Command line utilities set non-zero exit code if error happens in utility
> itself. So, even for havy corrupted database gfix will not set error code to
> non-zero if server can validate database and API call's returns without
> errors. Because *gfix itself* works w
--- In firebird-support@yahoogroups.com, Doug Chamberlin
wrote:
>
> I agree.
>
> Over the years I've used and built dozens of utility programs that use
the
> error code return value to reflect various status values unrelated to
the
> basic utility operation. Typically 0 means "no problems", posit
At 08:43 p.m. 10/04/2013, un_spoken wrote:
>Ok, I've checked this with gfix version: gfix version WI-V2.5.1.26351 Firebird
>2.5
>
>According to stackoverflow: I can test the error result of application like
>this:
>http://stackoverflow.com/questions/3452046/get-error-code-from-within-a-batch-fil
I agree.
Over the years I've used and built dozens of utility programs that use the
error code return value to reflect various status values unrelated to the
basic utility operation. Typically 0 means "no problems", positive values
mean basic ops problem (serious operating errors), negative values
