At 05:03 PM 9/12/2004 -0600, you wrote:

> >
> > Commit the ALTER, then do the DML statement.
> >
> > That should fix it.
>
>Did this and it doesn't work.
>
> > > Is this as designed or could it be a bug? Actually, I'm not even sure if
> >
> > Well, kind of " as designed " ... -> mixing DDL and DML isn't really
> > supported. IMO, it should simply raise an exception if you DML something
> > into not yet comitted DDL. That would solve the immediate problem of
> > unpredictable results and it would be clear it's not supported.
> >
>
>They shouldn't "normally" be mixed but it shouldn't cause this kind of
>problem. As a further test, I directed the IB_Connection component to point
>to my IB server instead of local for embedded FB. That should redirect the
>local gds32.dll (FB) to act as a client and it did. When I run the mixed
>DDL/DML on that setup, it works as expected, updating the correct field.
>
>I would consider this a bug in embedded. Does that sound reasonable?

Or a limitation...when you are logged into the embedded server, you are "no
user", even if your application login passed them into the application. Any
user can create an object. However, by default, a database object can only
be accessed by its creator or SYSDBA.

It would be hard to know what (if any) user creates the object when the
username isn't in the equation, but you could find out by querying the
RDB$USER_PRIVILEGES table. Maybe a series of committed GRANT ... ON ....
TO PUBLIC, preceding the DML, will do it.

But I suspect you would need to do more: use the login prompt to capture
the username and password (unfortunately you can't validate them against
security.fdb!) and then read them in the process of constructing the
ib_script. Then, at least, the privileges will ensure that the owner is
some definable "user" (rdb$user_privileges isn't linked to security.fdb at
all).

What is unknowable is what actually gets written to the ACL (Access Control
List, which is a blob of a particular subtype). There's the possibility
(probability?) that this "phantom owner" isn't detected by the ACL defence
system and the GRANTS to PUBLIC will be necessary whatever you do.

It can't be regarded as a "bug" really, since the full server is designed
to protect databases from unauthorised access and you can't have butter on
both sides of the bread. However, since you seem to have an interesting and
reproducible illustration of the effects, I think it would be useful to
raise it on the firebird-devel list for others to ponder/interpret/make
promises about...

Helen