What I'm gathering from your communication here is you are porting a BDE app
over to IBO. Such being the case, I hope you have spent time in the BDE to
IBO Conversion Guide. It is in the help file and on the internet. There's a
couple minor things I need to revise but it is a very helpful document.

I have painstakingly made it so that the capabilities of TDatabase, TTable
and TQuery, etc. are all preserved so it is possible to continue developing
with the process you are familiar with there. Whatever IBO has beyond that
you can ignore or at least patiently work your way into.

If you want to eliminate the metadata queries going on simply use a local
schema cache. This way you get the best of both worlds. Just remember to
delete the files if the metadata changes so it can refresh them. These can
be kept on a shared network folder too. See the SchemaCacheDir property of
the connection/database components.

If you clearly communicate what it is you are trying to accomplish in your
application then those of us who have the big picture will tell you what
properties to be concerned about.

What gets really irritating is when people come to the list and want people
to dissertate on properties when there isn't any real world context
available. It makes all the difference when people clearly communication
what they are trying to accomplish so we have some context to relate to. You
will get more of the big picture view of IBO by giving is something to
relate to you over than any amount of this property does this and that
property does that. At the very least I can promise you will get more
generous help from us.

Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

-- We may not have it all together --
-- But together we have it all --


"Bj�rge S�ther" <bjorge@...> wrote in message
news:b48ffb$ltu$1@......

> ""Jason Wharton"" <jwharton@...> skrev i melding
> news:b481ie$fpo$1@......
> > > Now I wonder: Why isn't IBO help file complete, or anything *near*
> > complete?
> >
> > Because I have not completed it yet. I acknowledge there is more work

that

> > can be done in it and you are invited to take part in the generation of
> > them. Is all that is necessary is you use the tags in the source code

that

> > my help file generation tool reads and constructs the help file from.

Let

> me
> > know if you are interested. I always appreciate what people are

committed

> to
> > behind their complaints.
>
> I believe I'm not quite there. It's about time, and it's about still not
> having the overall picture.
>
> > > I mean, this is a commercial product, right ?
> >
> > Not exactly. It is a trustware product which has a commercial aspect to

it

> > but it also has an open-source'ish aspect to it as well. The vast

majority

> > of people who use IBO do so for free, at least initially. Thus, I feel

it

> is
> > fine if I ask for those out in the community who can and have the drive

to

> > make some investment in IBO by contributing to it as they are able.
>
> I'd say that a packet price of $395 makes it "commercial". I can't see
> anything written that indicates I should plee for a free license. I am a
> professional, and the purpose is all commercial. In fact, I just invoiced
> the customer a number of $$ spent to convert an application from BDE to

IBO.

>
> > > I don't know how many extra
> > > hours I've been spending because of the poor help file, and someone

does

> > > actually pay for this. Either me & my family or my customers.
> > > And I don't mean *tutorials*, I mean *documentation*: "What does this
> > > property affect, and how ?" - and - when an explainatory text isn't
> easily
> > > written, an example or two.
> >
> > This is a general rule to apply. If you aren't sure what it does, ignore
> it.
>
> ...it's hard to ignore a property just because it doesn't have a complete
> help entry.
>
> > Property default values are designed to have normal industry standard
> > behavior. If you are confronting challenges on a creativity basis, like
> how
> > do I get IBO to do this in the most efficient way, that's when we invite
> you
> > to come to this list and partake of the best kind of documentation one
> could
> > wish for. Generous experts willing to share their insights and skills.
>
> This is fine, and I both ask and answer questions in forums every day.

What

> I usually *don't* do, is asking ten-folds of questions regarding this or
> that property. The reason is, usually a quick look into the help file or
> sources is all that's needed. This process has proved to be patience
> challenging with IBO. One example (which, oddly enough, was one of the

most

> troublesome things about moving to Direct Oracle Access, too) is the

SQLType

> constants - as they are not typed, there is absolutely no way to perform a
> quick lookup. I'll have to search IBO sources for ".SQLType", and go to

one

> serch hit, just to Ctrl-click the SQLType constant. "SQLType" has no

useful

> entry in help file. Why not use typed values ?
>
> > I also highly recommend you take some time in the sample applications.
> They
> > are a living example of how an IBO application can be put together.

Agreed

> > they aren't ideal for some things they are effective at demonstrating

all

> of
> > the basic and core usages. This is the next best type of assistance when
> > looking to give your software generation creativity some additional
> fluency.
>
> Now, there is *one* thing a sample application doesn't offer: Insight

about

> property settings. Or - at least - it's extremely hard to get the overall
> picture. That's not connected to IBO specifically, it goes for the Delphi
> concept. It just means sample apps must be built in a slightly different

way

> to be instructive. Whenever I select a TIB_Query in a sample application,
> How do I know what values are set to Non-default ? How do I get a quick

view

> of what's written in TStrings - type properties ? One possibility is
> shifting to textual representation of .dfm file - but there is still no

100%

> sure way of knowing what was default and what was actually *designed* so

in

> IDE.
> An example: I tried to make TIB_LookupCombo work, and I studied the sample
> app for an hour or so trying to locate the difference between my code and
> the sample app's. finally I had tried so many different combinations of
> property settings, I still wasn't 100% sure I knew what actually made it
> work.
>
> > Now, if you are comfortable with all of the above strategies then the

help

> > file is probably filled with useful information where these are
> > insufficient. Put another way, I've put in the help file that which I
> > generally expect to find. I don't use them all that much when I am using
> > others components. I just go to their sources, the best documentation

one

> > could ask for.
>
> I've been spending a few hours with the help file, some time with the

sample

> apps and tenfolds reading code.
> That's the reason why I'd like the source to be more readable. But as a
> general rule - if you wonder what some property is about, the help file
> should definately provide relevant info. Otherwise the generalized

component

> concept isn't worth much. AMOF is, it would be easier if there were no
> components, as setting properties would have to be clearly done within

.pas

> code files.
>
> Jason, I'm convinced that IBO components are indeed good. Lack of
> documentation & somewhat obscured sources reduces the overall usefullness

a

> lot, though. Well, er...at least - the overall economy. Remember - a
> programmer doesn't want to go further than what she or he *needs* to go.

The

> bigger a difference between IBO and other database access components, the
> higher the costs of implementing them.
> At a daily basis, I'm using IBO, BDE access, Direct Oracle Access,

DataSnap

> and an OO database framework. For reporting - QuickReports, Report Builder
> and Crystal Reports. I'd like them to be as similar as possible rather

than

> 100% optimized. *If* one has to choose.
> Somehow I feel like the optimization issues has had too much attention
> within IBO. There is much "optimization automation" going on under the

hood,

> and I'm having a real hard time trying to get rid of some of it. For
> instance, making the components stop asking for a complete list of tables.
> Whenever that happens, a few seconds delay is introduced. As I interpret

the

> code, it's part of a shcema cacheing mechanism which will eventually lead

to

> better performance. I just don't *want* this 2 seconds delay aimed at

making

> the application quicker afterwards. Shouldn't one be able to avoid such
> "investments" when it is not desired ?
> ..and the transactions stuff - once I left the TIBODatabase / TIBODataset
> components, I had a few days of work trying to make sure all objects were
> sharing the proper session/connection objects. The "smart" transaction
> handling makes it even harder to make it work.
>
>
> --
> Regards,
>
> Bj�rge S�ther
> bjorge@haha_itte.no
>
>
>
>
>

___________________________________________________________________________

> IB Objects - direct, complete, custom connectivity to Firebird or

InterBase

> without the need for BDE, ODBC or any other layer.
>

___________________________________________________________________________

> http://www.ibobjects.com - your IBO community resource for Tech Info

papers,

> keyword-searchable FAQ, community code contributions and more !
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>