Hi,

I've run into something interesting and wanted to see if anybody has any
ideas on what might cause this. Specifically it looks like the session
OnPassword event is not always fired and it started after I added
BeforeInsert and BeforeUpdate triggers. We have done a workaround but the
fact that this happened in the first place has piqued my interest.

Background
Our application uses DBISAM v4 (4.26b3) with local access. It's a
multi-threaded app and we've created a datamodule that houses a session and
database compoenent. The session AutoSessionName is set to true. Database,
any query or table we use refers to the session objects name for their
sessions to ensure we're multi-thread safe. There is couple of DMs around -
one for each thread of the application. Also some of our internal tables use
encryption and session object has the OnPassword even defined which simply
uses the session AddPassword and sets continue:=true.
All of this has worked just fine for number of years.

Recently we needed to build own own row edit detection so i added the
BeforeInsert and BeforeUpdate triggers. The trigger at this point is very
simple - it simply checks if known column name is present in the
CurrentRecord and if yes then sets it to Now (it's a timestamp field).

However the side effect of this is that i suddenly started getting
occasional prompts for the password when datamodule functions accessed the
encrypted tables - meaning the OnPassword event was not triggerred for some
datamodules.

It's not for every module - some of them work fine but it does happen. One
thing i have noticed is that when the prompt appears we are modifying
another (unencrypted) table (and triggers do fire) but we're only doing a
lookup into the encrypted one. I did do a debug session and it looks like
the DBISAM session does not think it has a procedure assigned to handle
OnPassword events but i'm not sure why it would go away!?.

Anyways, we've done a workaround by sprinkling some additional AddPassword's
around to places where we activate the session.

If you have any ideas what might cause this behaviour then please let me
know.

Regards,
Raul

Raul,

<< It's not for every module - some of them work fine but it does happen.
One thing i have noticed is that when the prompt appears we are modifying
another (unencrypted) table (and triggers do fire) but we're only doing a
lookup into the encrypted one. I did do a debug session and it looks like
the DBISAM session does not think it has a procedure assigned to handle
OnPassword events but i'm not sure why it would go away!?. >>

The session that is used for triggers is not the same session that you have
defined in your data module.  It is created by DBISAM specifically for use
with the triggers, so if you need to add a password, you need to do so in
the triggers before accessing the encrypted table(s).

--
Tim Young
Elevate Software
www.elevatesoft.com

Thanks Tim

Yes, i'm aware that a new session and database is created for the trigger.
However, I'm not using the session from triggers - trigger code simply
modifies the field in the CurrentRecord object passed in  (so i don't create
any new DBISAM objects or even reference sessions or database in there
directly).

The encrypted table lookup is definitely part of the DM code path and uses
the session there. Everything works if i add the AddPassword command after
the mysession := active in DM - so the mystery remains for as to why the
OnPassword event is not called in some cases even though it is defined.

Raul



"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:8D5AD416-30F2-4125-BE0E-E3663EA4E7F7@news.elevatesoft.com...
> Raul,
>
> << It's not for every module - some of them work fine but it does happen.
> One thing i have noticed is that when the prompt appears we are modifying
> another (unencrypted) table (and triggers do fire) but we're only doing a
> lookup into the encrypted one. I did do a debug session and it looks like
> the DBISAM session does not think it has a procedure assigned to handle
> OnPassword events but i'm not sure why it would go away!?. >>
>
> The session that is used for triggers is not the same session that you
> have defined in your data module.  It is created by DBISAM specifically
> for use with the triggers, so if you need to add a password, you need to
> do so in the triggers before accessing the encrypted table(s).
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>

Raul,

<< The encrypted table lookup is definitely part of the DM code path and
uses the session there. Everything works if i add the AddPassword command
after the mysession := active in DM - so the mystery remains for as to why
the OnPassword event is not called in some cases even though it is defined.
>>

Well, 99.999% of the time when there's a problem in a multi-threaded
application, it's the multi-threading not being done properly that is the
source of the problem.  If you want me to take a look at the source code,
just email it over and I'll take a look.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thanks Tim for the offer.

I can't send the source code but will try to put a sample project together
using same approach for DBISAM compoenents. If the issue still exists there
then will send it over (and if not then will debug own code more

Raul