At 11:02 AM 05-07-01 +0200, you wrote:

>Helen,
> But when I make a list of fields in the Delphi Fields Editor the
>computed fields have received property ReadOnly = TRUE.

IBOQuery behaves exactly the same. In your first posting, you said you tested the column for ReadOnly and it was False...well, either I misunderstood you or you were mistaken. In the next posting, I happened to mention that native Delphi lets users modify the contents of these fields in controls, even though they are read-only. That is Delphi VCL behaviour, not IBO.

There is no way that a computed column can be writable (unless you write a parser for it and do some kind of custom update...but we weren't talking about that). In fact, the internal dataset of the TIBOQuery probably even overrides that particularly silly inherited behaviour and disallows modification of computed columns in the UI as well...

But my point was that the vcl has no way to determine what *kind* of data it is getting from a column in a server table (even though it knows, because the database says so, that it is read-only).

>I did not have to set them manually.

I think you will see a computed column as fkData in the Fields Editor under the BDE and that you DO have to set it manually if you want the application to know it is fkInternalCalc.

>This problem is very important for me because in the same
>iboQuery I change property SQL and try to get fields properties.

Why is it important for your application to distinguish between fkData and fkInternalCalc? And, if it is important for some special reason, can't you set the FieldKind property in the AfterPrepare event when your new SQL is in place?

Regards,
Helen

All for Open and Open for All
InterBase Developer Initiative · http://www.interbase2000.org
_______________________________________________________