At 07:53 AM 19/04/2009, you wrote:

>I've recently upgraded from Fb/1.5 to Fb/2.1.2. Applications seems
>to work fine. Except one.
>
>Delphi (BDS) 2006
>IBO version is 4.8.7
>Windows XP Pro SP2
>
>The program excepts on connecting. The code goes like this:
> fDM.cnM2.LoginPrompt:=false;
> fDM.cnM2.Username:='ABCDE';
> fDM.cnM2.Password:='abcde';
> fDM.cnM2.Connected:=true;
>Tracing the code, I get this far (it never reaches the next statement).
>This is in the FormShow for the main form. Using SYSDBA works fine.
>
>Now, the user (ABCDE) does not have any privileges to anything in the
>database. I use this just to connect, read a couple of values from a
>table (where PUBLIC has been granted all privileges), and then disconnect.
>The error messages is:
>---------------
>Unable to perform operation. You must be either SYSDBA or owner of
>the database.
>---------------
>I never get to the 'read a couple of values' bit since the connect fails.

The cause of this "problem" is documented all over the place in the release notes. You first encounter it in the "General Notes" section"

Important Change to API DPB Parameters
A long-standing, legacy loophole in the handling of DPB parameters enabled ordinary users to make connection settings that could lead to database corruptions or give them access to SYSDBA-only operations. The loophole
has been closed, a change that could affect several existing applications, database tools and connectivity layers (drivers, components). Details are in Chapter 3, Changes to the Firebird API and ODS.
.....
Note, it also affects v.2.0.5.

This doesn't change the API from the POV of the driver interface, but it will certainly surface as a problem in applications that have (accidentally or inadvisedly) tried to use them in the past.

Find these parameters in all of your connection objects' properties, not overlooking the Params property, which often hides a few undesirable settings.

>Needless to say, this used to be working fine (under Fb/1.5). And I
>can connect with IB_SQL using ABCDE/abcde. Of course trying to
>browse tables gives an error about "no permission for read/select
>access to TABLE XXXX". After that, I can view contents of the one
>table that this user is interested in.

It is not a permissions issue, nor indeed a database-specific issue at all. It's about what ordinary users are allowed to do at connection time.

>There is another app that works ok with a non-SYSDBA user.
>I've converted the old security database to security2.fdb, but not
>changed LegacyHash in the firebird.conf.

It's not related to password parsing either. ;-)

Helen