SQL Anywhere database - Possible bug in ConnectFailed Event (does not fire event)

Author

Possible bug in ConnectFailed Event (does not fire event)

David DeRam

2005-04-22, 11:23 am

I'm having problems with the ConnectFailed event not firing.

I have it simplied reproducing it in the following steps:
1. Create a new database (I used a trans log, no mirror, no java, and 8k
page size, version 9.0.1.1751)
2. Using dba...Create a table...see below
3. Using dba...Create an event for ConnectFailed...see below
4. Close *all* connections to the database (if any connections are open it
will work fine)
5. Attempt to connect with a bad login so it fails. Do this multiple
times.! (I did this with the standalone, not with a network server - but
I'm pretty sure it will happen either way)

The problem is that there will only be one record written to the table.
After writing the first record it appears as if the event does not get
fired. Remember to be sure that no other connections are open while you are
logging in with the bad uid/pwd. Also it is interesting that if the row is
deleted the EVENT will insert another row but will stop there.

I have spent about 8 hours trying to figure this out and I think it is a
bug. If anyone can confirm or deny this I would appreciate it. It could be
something silly I am doing.

Thank you.

CREATE TABLE st_failed_logins
(failedloginid integer NOT NULL default autoincrement,
userid long varchar,
PRIMARY KEY(failedloginid))

CREATE EVENT SecurityCheckLoginFa
iled
TYPE ConnectFailed
HANDLER
BEGIN
INSERT INTO st_failed_logins (userid) VALUES ('FAILED');
END

Breck

2005-04-22, 1:23 pm

Try adding a COMMIT.

> I'm having problems with the ConnectFailed event not
> firing.
>
> I have it simplied reproducing it in the following steps:
> 1. Create a new database (I used a trans log, no mirror,
> no java, and 8k page size, version 9.0.1.1751)
> 2. Using dba...Create a table...see below
> 3. Using dba...Create an event for ConnectFailed...see
> below 4. Close *all* connections to the database (if any
> connections are open it will work fine)
> 5. Attempt to connect with a bad login so it fails. Do
> this multiple times.! (I did this with the standalone,
> not with a network server - but I'm pretty sure it will
> happen either way)
>
> The problem is that there will only be one record written
> to the table. After writing the first record it appears as
> if the event does not get fired. Remember to be sure that
> no other connections are open while you are logging in
> with the bad uid/pwd. Also it is interesting that if the
> row is deleted the EVENT will insert another row but will
> stop there.
>
> I have spent about 8 hours trying to figure this out and I
> think it is a bug. If anyone can confirm or deny this I
> would appreciate it. It could be something silly I am
> doing.
>
> Thank you.
>
>
> CREATE TABLE st_failed_logins
> (failedloginid integer NOT NULL default autoincrement,
> userid long varchar,
> PRIMARY KEY(failedloginid))
>
> CREATE EVENT SecurityCheckLoginFa
iled
> TYPE ConnectFailed
> HANDLER
> BEGIN
> INSERT INTO st_failed_logins (userid) VALUES ('FAILED');
> END
>
>
>

Bruce Hay

2005-04-22, 8:23 pm

Is the database left running between connection attempts, or are you
auto-starting it? If the latter, then the database may be shutting down
before the event has a chance to execute. In that case, you might want to
try with the latest 9.0.1 EBF, since there were several fixes related to the
timing of operations at database shutdown.

Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
Developer Community at http://www.ianywhere.com/developer

"David DeRam" < ns_xxxdderam@progeny
ns_xxx2000.com> wrote in message
news:42691bf8$1@foru
ms-2-dub...
> I'm having problems with the ConnectFailed event not firing.
>
> I have it simplied reproducing it in the following steps:
> 1. Create a new database (I used a trans log, no mirror, no java, and 8k
> page size, version 9.0.1.1751)
> 2. Using dba...Create a table...see below
> 3. Using dba...Create an event for ConnectFailed...see below
> 4. Close *all* connections to the database (if any connections are open it
> will work fine)
> 5. Attempt to connect with a bad login so it fails. Do this multiple
> times.! (I did this with the standalone, not with a network server - but
> I'm pretty sure it will happen either way)
>
> The problem is that there will only be one record written to the table.
> After writing the first record it appears as if the event does not get
> fired. Remember to be sure that no other connections are open while you
are
> logging in with the bad uid/pwd. Also it is interesting that if the row
is
> deleted the EVENT will insert another row but will stop there.
>
> I have spent about 8 hours trying to figure this out and I think it is a
> bug. If anyone can confirm or deny this I would appreciate it. It could
be
> something silly I am doing.
>
> Thank you.
>
>
> CREATE TABLE st_failed_logins
> (failedloginid integer NOT NULL default autoincrement,
> userid long varchar,
> PRIMARY KEY(failedloginid))
>
> CREATE EVENT SecurityCheckLoginFa
iled
> TYPE ConnectFailed
> HANDLER
> BEGIN
> INSERT INTO st_failed_logins (userid) VALUES ('FAILED');
> END
>
>
>

David DeRam

2005-04-22, 8:23 pm

Thanks for the suggestion. I tried that. It did not work. It works in
9.0.02

<Breck> wrote in message news:426933e4.12a4.1681692777@sybase.com...[color=darkred]
> Try adding a COMMIT.
>

David DeRam

2005-04-22, 8:23 pm

Bruce.

We were using autostart. If I left the database running it worked fine.

We had disks here for 9.0.2.2451. We loaded that and it looks like it is
working like a champ.

Thanks for your help. That was a big sigh of relief for us.

Dave

"Bruce Hay" < h_a_y@i~a~n~y~w~h~e~
r~e.c_o_m> wrote in message
news:42694641$1@foru
ms-2-dub...
> Is the database left running between connection attempts, or are you
> auto-starting it? If the latter, then the database may be shutting down
> before the event has a chance to execute. In that case, you might want to
> try with the latest 9.0.1 EBF, since there were several fixes related to
the
> timing of operations at database shutdown.
>
> Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
> Developer Community at http://www.ianywhere.com/developer
>
> "David DeRam" < ns_xxxdderam@progeny
ns_xxx2000.com> wrote in message
> news:42691bf8$1@foru
ms-2-dub...
it[color=darkred]
but[color=darkred]
> are
> is
could[color=darkred]

> be
>
>

Sponsored Links