TD5.2 Oracle router does not observe password grace period

[PAVEL.LOGVIN]

When testing applications converted to Team Developer 5.2 we have uncovered an issue with the new Oracle router that prevents us from releasing converted applications to production.

The problem is with a new Oracle router coupled with the Team Developer 5.2. When the user password is about to expire and the password expiration grace period is in effect all applications still allow users to use their old passwords during this grace period. So did the old Centura 2.1 Oracle native router. However, this is not the case with the new Oracle router that refuses to connect to the database and ignores the password expiration grace period.

The full case description can be found here:

• https://support.guptatechnologies.com/su ... =20&t=3998

This issue prevents us from allowing users to be notified that they must change their passwords. Instead, they are locked out and the help desk would need to be notified and have to change each individual password. This issue would cause the tremendous time and efficiency loss in our call centers and would make questionable all possible benefits from the conversion to Team Developer 5.2.

Has anyone ever had the similar problem? Is there any possible work around?

Thank you in advance.

Pavel

[Jeff Luther]

Hi, Pavel: I found out there was an earlier defect on this issue, which has just been reopened, based on your report: TD-388

I'm not familiar with the issue myself but was told that a couple possible workarounds were suggested until this gets resolved:

1/ trapping the error when it happens from TD and sending a message to the user so they can act upon it.

2/ use OLEDB instead of the [Oracle] router [though that would likely require further testing on your part].

Let me know if either of these options, or you come up with something else, will work for you. And if you find another alternative, let us know what that is. It could prove very useful to others as well. Thanks!

[PAVEL.LOGVIN]

Thanks, Jeff, for your prompt reply.

1/ trapping the error when it happens from TD and sending a message to the user so they can act upon it.

We can trap 20002 error and can show the message about password expiration. But, this seems to be the only thing we can do.

When the error occurs SqlConnect returns a non-null connection, but this Sql Handle is not usable. When I tried to use the obtained connection after 20002 error occurred I got "Invalid Connection" error.

This means that we would still have to tell our users that their passwords expired and instruct them to go to the supervisor who would be kept busy resetting the expired user passwords.

2/ use OLEDB instead of the [Oracle] router [though that would likely require further testing on your part].

Change to OLEDB may be too drastic and would require more work. It is not clear if the OLEDB would allow for using anonymous PL/SQL blocks and stored procedures. We have a heavy load of them.

Thanks.

[Jeff Luther]

Pavel: A TD defect got reopened about this issue: TD-388

I don't have anything further as to when it will be fixed, etc. Does your company have a licensed support contract from Unify?

[PAVEL.LOGVIN]

It looks like that our contract with Unify does not include Technical Support.

Thanks.