Subject | Re: [IBO] Re: fields in readonly? |
---|---|
Author | Helen Borrie |
Post date | 2006-08-15T00:22:17Z |
At 06:50 AM 15/08/2006, you wrote:
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.
Helen
> > >I create a TIBOQuery at run-time, when I try to edit the values of aReadOnly is a data attribute.
> > >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'...
>It's weird, since this issue arrived when using a new version ofI don't think so....see comments below.
>IBObjects.
> > What is the SQL of this query?Joined sets are always read-only. This is the nature of things with
>
> 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)'
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.
Helen