> Try this with example - you should get meaningful diags about missing
> key. But pay attention - that's diags from crypt plugin, i.e. it depends
> upon plugin how to react to missing callback (which means missing key
> provided by current client). BTW, in some usage schemas callback is not
>
On 28.08.2017 17:47, Jiří Činčura wrote:
Ahh - agreed, the reason why lib failed to load is missing in diags.
Bad luck for me.
The Callback.dll is actually loaded fine (at least from OS perspective):
16:41:38,1377272ConsoleApp1.exe 7240Load Image
There's nothing after this. No further attempts to load anything.
Just exception from Firebird and then my application closes from
application side of things.
--
Mgr. Jiří Činčura
https://www.tabsoverspaces.com/
On Mon, Aug 28, 2017, at 16:51, Dimitry Sibiryakov wrote:
> 28.08.2017 16:47, Jiří
> Ahh - agreed, the reason why lib failed to load is missing in diags.
Bad luck for me.
The Callback.dll is actually loaded fine (at least from OS perspective):
16:41:38,1377272ConsoleApp1.exe 7240Load Image
On 28.08.2017 17:18, Jiří Činčura wrote:
Jiri, please take a look at the sample provided with FB3 - it works with
both embedded & remote.
I'm looking at that. But I don't know why the loading is failing (while
the same setup work in server mode). It would be nice to have bit more
verbosity,
> Jiri, please take a look at the sample provided with FB3 - it works with
> both embedded & remote.
I'm looking at that. But I don't know why the loading is failing (while
the same setup work in server mode). It would be nice to have bit more
verbosity, maybe in log (but there's nothing).
BTW
>Most likely bitness of plugin DLL doesn't match bitness of fbclient.
Both 64bit. In fact I'm using same "installation" for server and there
it works fine.
Callback.dll:
File Version Information:
File Version: 1.0.0.1
Product Version: 1.0.0.1
File Type:
Hi *,
how's the crypt key callback expected to work on Embedded? So far I
haven't done anything to the .NET code, but when I try to connect to an
encrypted database I get:
Error loading plugin Callback
Module \plugins/Callback exists but can not be loaded
Not sure whether it's because I haven't
Hi *,
is there a way to create encrypted database right away (compared to
creating database and then altering it to enable encryption)?
--
Mgr. Jiří Činčura
https://www.tabsoverspaces.com/
--
Check out the vibrant tech
On Mon, 28 Aug 2017 14:47:43 +0300 Dmitry Yemanov wrote
> 28.08.2017 14:42, Adriano dos Santos Fernandes wrote:
>
> > Paul, both things I've verified in 3.0 snapshot builds.
> >
> > I thought these zip kits was using the same process used to generate
> > release zip kits.
>
> So the problem
On 28/08/2017 08:34, Paul Reeves wrote:
> On Sat, 26 Aug 2017 19:04:28 -0300 Adriano dos Santos Fernandes wrote
>
>> Hi!
>>
>> I found two problems with include files:
>>
>> - ibase.h has #include "consts_pub.h"
> I can't find that line. I diffed the alpha1 ibase.h with the one from
> 3.0.2 and
On Sat, 26 Aug 2017 19:04:28 -0300 Adriano dos Santos Fernandes wrote
> Hi!
>
> I found two problems with include files:
>
> - ibase.h has #include "consts_pub.h"
I can't find that line. I diffed the alpha1 ibase.h with the one from
3.0.2 and everything looks OK to me. There is new stuff added
28.08.2017 12:49, Slavomir Skopalik wrote:
And by the way, Embarcadero in delphi IBX code don't counted with that.
FIBC and all derivates has the worst event component that I've ever seen. It can work
only in simplest cases and only by stupid luck.
--
WBR, SD.
But this mean to have some global dispatcher that will die as last
object during termination process.
This is far from clean programing.
And by the way, Embarcadero in delphi IBX code don't counted with that.
Slavek
28.08.2017 11:09, Paul Reeves wrote:
The event listener should really be
28.08.2017 12:40, Slavomir Skopalik wrote:
there are two different situation:
1. cancel is call from different thread
2. cancel is called from call back
You don't need (and actually, cannot) cancel events from callback.
Why this:
If you are create a object that wraps this interface,
Thread is created inside gds32.dll.
Slavek
Maybe I'm missing something, but I seem to recall from the code that
you posted that your listener is running on a timer in the main thread.
The event listener should really be running in its own thread.
Have you tried that?
Paul
28.08.2017 11:09, Paul Reeves wrote:
The event listener should really be running in its own thread.
Actually, callback is already called in its own thread. If a programmer is aware of
that and coded it properly - there is no problem with extra calls.
--
WBR, SD.
On Mon, 28 Aug 2017 11:01:16 +0200 Slavomir Skopalik wrote
> >
> > On 28.08.2017 04:15, Slavomir Skopalik wrote:
> >> Should I create ticket for this?
> >>
> >
> > No. Removing that call will break old code.
>
> You mean, old code will not crash so often.
> How much time I have to wait to
28.08.2017 3:15, Slavomir Skopalik wrote:
From programing theory, no call back after successful cancel event is allowed.
From your theory, how should be thread waiting with isc_event_wait() to be aborted
without calling callback on cancel?
--
WBR, SD.
28.08.2017 11:01, Slavomir Skopalik wrote:
How much time I have to wait to be sure that no more call back?
Or is there other technique how to solve it?
Yes: ritht callback routine can only set flags. In any case it can call (almost)
nothing from ISC API and have to return ASAP.
--
WBR,
On 28.08.2017 04:15, Slavomir Skopalik wrote:
Should I create ticket for this?
No. Removing that call will break old code.
You mean, old code will not crash so often.
How much time I have to wait to be sure that no more call back?
Or is there other technique how to solve it?
From
On 28.08.2017 04:15, Slavomir Skopalik wrote:
Should I create ticket for this?
No. Removing that call will break old code.
From programing theory, no call back after successful cancel event is
allowed.
To be precise - it happens during event cancellation.
Slavek
Hi all,
I'm testing
22 matches
Mail list logo
