On 12/21/21 18:12, Jiří Činčura wrote:
Are you sure you've shown me dump correctly? Here must be one more
That's what I see in WireShark.
Could you maybe describe in one or two sentences what the fields in p_batch_cs
mean logically?
typedef struct p_batch_cs // completion state
{
OBJCT p_batch_statement; // statement object
ULONG p_batch_reccount; // total records
Total number of messages(records), processed by batch.
ULONG p_batch_updates; // update counters
Number of update counters (records updated per each message), array of
4-byte integers, passed after p_batch_cs.
ULONG p_batch_vectors; // recnum + status vector pairs
Detailed info about errors in batch. For each error over the wire server
sends number of message (4-byte integer) and status vector in standard
way (exactly like in op_response). Number of such pairs is
p_batch_vectors. Sent after an array of update counters.
ULONG p_batch_errors; // error's recnums
Numbers of records with error. Used when too many errors took place. For
each error server sends number of message for which execution of SQL
statement failed. And yes - such number is 4-byte integer, data is sent
after an array of detailed error info.
} P_BATCH_CS;
Especially with regards to options one can send in BPB.
One need not care about that options when parsing completion state.
(Certainly, that options do affect completion state - but it contains
all required info for parsing inside, no need to take that options into
an account). Moreover - to be precise that options are recomendations
for server, when getting for example close to OOM server can decrease
count of detailed error info.
It's difficult to do the decoding of packet, filling some local values and at
the same time reason about the outcomes.
This format is definitely not the simplest one...
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
