Thank you for your answer.

I think the best I can do is to avoid letting the user to set this
field, whether it is null or not. Instead it should be set only by the
trigger, so that the SQL sentence doens't have this field included.

Aldo

El 09/12/14 a las 18:20, Mark Rotteveel mark@...
[firebird-support] escibió:

> On 9-12-2014 21:42, Aldo Caruso aldo.caruso@...
> [firebird-support] wrote:
>> I'm inserting records from PHP / Apache / Ubuntu in a Firebird
>> table. This table has an integer non null field, and a before insert
>> trigger which takes care of setting it to the next integer value in case
>> the user attempts to set this field to null.
>>
>> If this field is set to any integer from PHP there is no problem.
>>
>> On the other hand, if it is set to null ( lefting to the trigger
>> the task of assigning it ) any of the following behaviours happens
>> (randomly)
>>
>> 1) A -804 error is shown in the apache log, with the message: "Dynamic
>> SQL Error SQL error code = -804 Incorrect values within SQLDA structure"
> Error numbers are not really helpful (eg -804 is 10 different errors),
> it is better to provide the specific error code (which for this error
> message is 335544713 (or isc_dsql_sqlda_value_err).
>
>> 2) The Apache sub process is aborted, with the log message: "child pid
>> NNNN exit signal Segmentation fault (11)"
>>
>> 3) A random integer is assigned to the field. This behaviour is by far
>> less frequent, but happened a couple of times.
> The problems you describe above are possibly caused by memory corruption
> issues. It sounds like you or an intermediate layer is incorrectly
> reading from or writing values into an XSQLDA (the struct used for
> getting information into and out of Firebird), overwriting other memory
> areas or reading (or causing Firebird to read) beyond process memory.
>
> As you mention the field is NOT NULL, then most likely you (or the
> intermediate layer) thinks it is possible to set a non-nullable XSQLVAR
> to NULL without setting the sqltype to nullable. I have been bitten by
> that problem myself once in the native sub-protocol in Jaybird (see
> http://tracker.firebirdsql.org/browse/JDBC-271 and
> http://tracker.firebirdsql.org/browse/CORE-3913).
>
> The problem might be that fbclient does not check the null-indicator if
> the sqltype is not-nullable, so it will attempt to read the sqldata
> field that is either set to null, or worse pointing to a random memory
> location. Another cause could be the reverse: the type has been made
> nullable, but the sqlind value hasn't been set with similar results.
>
> As I have no idea about the PHP side of things I can only guess about
> workarounds, etc.
>
> Mark