| Subject | Re: R: [IBO] for Jason: TIBOQuery vs. TFIBDataset speed test |
|---|---|
| Author | Lester Caine |
| Post date | 2005-05-26T08:31:27Z |
Enrico Raviglione wrote:
When I FIRST started using IBO I hit all sorts of problems, and gave up
- spending another 6 months trying to make BDE work. Which it never did!
I was given a deadline to fix things or scrap Interbase ( this was
pre-Firebird days ;) ). So I went back to IBO and started again, but I
did NOT import any of the BDE style stuff at all. Within two weeks I had
a stable system, fast, running reasonably. There were still problems,
but I knew who to blame, and was waiting for IB6 to fix them.
You have probably read the history yourself, but as soon as I had the
first production build of Firebird, all the rest of the problems went
away, and we have been running applications 24/7 since!
Borland had the option to go the IBO route ( and pay Jason lots of money
;) ) when they started with IBX, but instead they went their own way,
and actually created code that required Jason to rename parts of the
legacy sections to simple to avoid name conflicts. IBObjects is a very
powerful framework, the legacy stuff has to be persuaded to follow the
rules, and not using it at all helps!
That said, I think that the niggle with Boolean can probably be sorted,
but I would suggest you think about using Client/Server. I build queries
for the data I want, combining tables on the server, and playing with
those scripts when I find a slow one. I have never used a 'persistent
field' in the client and just read the data direct from the query. I'm
sure that it is building all of that unnecessary overhead that *IS* the
problem, since IBO only needs it to provide legacy interfaces.
( And I am probable talking a load of rubbish, but I am more than happy
*NOW* with performance ;) )
--
Lester Caine
-----------------------------
L.S.Caine Electronic Services
>>IBO searches in metadata for Domains and SQL types after a miss onLooks as if we hit the same point at the same time ;)
>
> field name. That creates two extra searches (alas >in memory) per
> operation on fields without entries.
>
>>Is FieldEntryType set to anything? If it is try setting it to [].
>
> FieldEntryType = [fetDomainName]
>
> I need to use Boolean then i don't know any other method for do that.
When I FIRST started using IBO I hit all sorts of problems, and gave up
- spending another 6 months trying to make BDE work. Which it never did!
I was given a deadline to fix things or scrap Interbase ( this was
pre-Firebird days ;) ). So I went back to IBO and started again, but I
did NOT import any of the BDE style stuff at all. Within two weeks I had
a stable system, fast, running reasonably. There were still problems,
but I knew who to blame, and was waiting for IB6 to fix them.
You have probably read the history yourself, but as soon as I had the
first production build of Firebird, all the rest of the problems went
away, and we have been running applications 24/7 since!
Borland had the option to go the IBO route ( and pay Jason lots of money
;) ) when they started with IBX, but instead they went their own way,
and actually created code that required Jason to rename parts of the
legacy sections to simple to avoid name conflicts. IBObjects is a very
powerful framework, the legacy stuff has to be persuaded to follow the
rules, and not using it at all helps!
That said, I think that the niggle with Boolean can probably be sorted,
but I would suggest you think about using Client/Server. I build queries
for the data I want, combining tables on the server, and playing with
those scripts when I find a slow one. I have never used a 'persistent
field' in the client and just read the data direct from the query. I'm
sure that it is building all of that unnecessary overhead that *IS* the
problem, since IBO only needs it to provide legacy interfaces.
( And I am probable talking a load of rubbish, but I am more than happy
*NOW* with performance ;) )
--
Lester Caine
-----------------------------
L.S.Caine Electronic Services