On 13-4-2015 20:02, Mark Rotteveel wrote:
> This unfortunately gives the same error. I tried something similar
> yesterday (I assigned the handle to a temp variable before
> callback->setEvents(events) and assigned it to id at the end), but that
> lead to a different error (an invalid memory access
On 13-4-2015 11:28, Alex Peshkoff wrote:
>
>
> On 11.04.2015 11:57, Mark Rotteveel wrote:
>> On 6-4-2015 12:40, Mark Rotteveel wrote:
>>> If I add a small pause (1 to 5 milliseconds) between steps 2 and 3, the
>>> problem doesn't occur. This seems to indicate it is a
>>> threading/concurrency issue
On 11.04.2015 11:57, Mark Rotteveel wrote:
On 6-4-2015 12:40, Mark Rotteveel wrote:
If I add a small pause (1 to 5 milliseconds) between steps 2 and 3, the
problem doesn't occur. This seems to indicate it is a
threading/concurrency issue with invoking a callback in parallel with
the invocation
On 6-4-2015 12:40, Mark Rotteveel wrote:
> If I add a small pause (1 to 5 milliseconds) between steps 2 and 3, the
> problem doesn't occur. This seems to indicate it is a
> threading/concurrency issue with invoking a callback in parallel with
> the invocation of isc_que_events for a different event
On 6-4-2015 12:21, Alex Peshkoff wrote:
> On 04/06/15 13:08, Mark Rotteveel wrote:
>> On 6-4-2015 11:53, Dimitry Sibiryakov wrote:
>>> 06.04.2015 11:49, Mark Rotteveel wrote:
The error itself is my own fault (I shouldn't have called
isc_event_counts which zeroed out the event buffer as th
On 04/06/15 13:08, Mark Rotteveel wrote:
> On 6-4-2015 11:53, Dimitry Sibiryakov wrote:
>> 06.04.2015 11:49, Mark Rotteveel wrote:
>>> The error itself is my own fault (I shouldn't have called
>>> isc_event_counts which zeroed out the event buffer as the result buffer
>>> was still empty), but I do
06.04.2015 12:08, Mark Rotteveel wrote:
> If your theory is correct
At least this is the only case when I always get callback routine called
with NULL
parameter.
--
WBR, SD.
--
BPM Camp - Free Virtual Workshop M
On 6-4-2015 11:53, Dimitry Sibiryakov wrote:
> 06.04.2015 11:49, Mark Rotteveel wrote:
>> The error itself is my own fault (I shouldn't have called
>> isc_event_counts which zeroed out the event buffer as the result buffer
>> was still empty), but I don't understand that I get an event callback
>>
06.04.2015 11:49, Mark Rotteveel wrote:
> The error itself is my own fault (I shouldn't have called
> isc_event_counts which zeroed out the event buffer as the result buffer
> was still empty), but I don't understand that I get an event callback
> with length zero after step 3.
>
> As a sidenote: I
On 6-4-2015 11:08, Alex Peshkoff wrote:
> There were changes. But must say that the symptom you get are quire
> strange - events block is 'const UCHAR*' parameter and does not seem to
> be modified wherever in client code. On the other hand certainly
> something bad may happen - code was really mod
On 04/04/15 19:39, Mark Rotteveel wrote:
> What is the current status of events in the Firebird 3 client library?
> Are there known problems?
>
> I am currently reimplementing events in Jaybird, and when I talk to a
> Firebird 2.5.4 fbclient.dll it works ok, but when I talk to a Firebird
> 3.0.0.31
On Sat, Apr 04, 2015 at 06:39:06PM +0200, Mark Rotteveel wrote:
> What is the current status of events in the Firebird 3 client library?
> Are there known problems?
While testing the IPv6 implementation, I also tested events (as there
were some changes to aux connection handling). I repeated the
What is the current status of events in the Firebird 3 client library?
Are there known problems?
I am currently reimplementing events in Jaybird, and when I talk to a
Firebird 2.5.4 fbclient.dll it works ok, but when I talk to a Firebird
3.0.0.31733 fbclient.dll (snapshot from last week), it fa
13 matches
Mail list logo
