Subject [Solved] Re: fields in readonly?
Author zifnabbe
--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> At 06:50 AM 15/08/2006, you wrote:
>
> > > >I create a TIBOQuery at run-time, when I try to edit the values
of a
> > > >record, it isn't possible anymore... I've checked it and it is
because
> > > >the database field is read-only (the dataset itself is not).
> > > >
> > > >If I manually change the readonly value to false, then I can
edit the
> > > >value again and everything works as normal... but it is surely
not the
> > > >idea that I iterate all controls of a form and change it's readonly
> > > >status to false...
> > >
> > > No, it's not. But why would you "iterate all controls of a form" if
> > > it's a database field that is arriving read-only?
> >
> >to adjust them to 'not being readonly'...
>
> ReadOnly is a data attribute.
>
> >It's weird, since this issue arrived when using a new version of
> >IBObjects.
>
> I don't think so....see comments below.
>
>
> > > What is the SQL of this query?
> >
> > result := 'SELECT PERSONS.PERSON_ID,'+#13#10
> > +'PERSONS.PERSON_FIRSTNAME,'+#13#10
> > +'PERSONS.PERSON_SECONDNAME,'+#13#10
> > +'PERSONS.PERSON_LASTNAME,'+#13#10
> > +'PERSONS.PERSON_BIRTHDATE,'+#13#10
> > +'PERSONS.PERSON_STREETNAME,'+#13#10
> > +'PERSONS.PERSON_STREETNUMBER,'+#13#10
> > +'PERSONS.PERSON_BUSNUMBER,'+#13#10
> > +'PERSONS.PERSON_REFUSAL,'+#13#10
> > +'PERSONS.PERSON_DECIESED,'+#13#10
> > +'PERSONS.PERSON_CREATED,'+#13#10
> > +'PERSONS.PERSON_MODIFIED,'+#13#10
> > +'PERSONS.POSTCODE_ID,'+#13#10
> > +'POSTCODES.CITY'+#13#10
> > +'FROM PERSONS'+#13#10
> > +'LEFT OUTER JOIN POSTCODES ON
> >PERSONS.POSTCODE_ID=POSTCODES.POSTCODE_ID'+#13#10
> > + 'WHERE (PERSON_ID = :PersonID)'
>
> Joined sets are always read-only. This is the nature of things with
> SQL - it has nothing to do with what IBO (or any other data access
> interface) might do from version to version.
>
> In IBO It is possible to make the set "updatable" by providing
> XxxxSQL properties for the dataset AND valid KeyLinks or, in some
> cases, to make fields in one table of this set updatable by setting a
> KeyRelation property and setting RequestLive true.
>
> Therefore, if the same set was updatable previously, check that you
> have set up all of these properties appropriately before you open
the set.
>
> However, for this query, the join (and all of its complications) is
> quite unnecessary. Take out the join and replace it with a
> correlated subquery on POSTCODES. Also fix up your WHERE clause. It
> needs a table qualifier on PERSON_ID.
>
> Now, all that said, there appears to be a bug in a method in
> ib_components.pas in the latest subrelease of IBO that might be
> playing a part in the behaviour difference you are seeing. However,
> try fixing up things as I have suggested. Bug or no bug, you still
> need to make this right. Test whether it changes things and report
back.

I've made the modifications and it works indeed. So, I must have done
something else besides upgrading IBO to receive the problem. Now the
problem is solved. Thanks.

But another question (concerning the correlated subquery):

Is a correlated query always better than a join? Or is it only better
in this case (ie a point query). I assume it is only better in this
case and that a join is still better in the case when not using the
"WHERE (PERSON_ID = :PersonID)"


>
> Helen
>