| Subject | [IBDI] Re: About IBX and Firebird |
|---|---|
| Author | David Cornelius |
| Post date | 2002-04-12T22:47:53Z |
c) I have no problem with that--although it's a little inconvenient.
The minor complaint I have with the help file is on properties such as
BufferSynchroFlags, TIB_CommitAction, OrderingLinks, and RecordCountAccurate,
where there is little, if any, explanation. In the case of
RecordCountAccurate, the property name seems self-explanatory, but it raises all
kinds of questions in my mind such as: "Does this decrease performance?" or "Why
is this property needed and do I need to worry about it?". I can take
Jason's advice to ignore these things I don't understand for now, but I may soon
need special features and not realize there's an option that would solve a
problem efficiently.
d) Read the source files? I don't have time for that!
e) Yes, the lists are very active with lots of experienced, helpful
people. This is indeed the most valuable resource.
David Cornelius
You have to:
a) read "getting started guide". It's cheap and very useful
b) study the samples that come with
c) understand that the help for a property of a component very often has to bee searched for the ancestor of that component, where is widely explained (at first I was complaining for the "scarne" help wondering where was the huge help content IBO people was talking about... it's there!)
d) read the source, Luke! In the *.INT (interface) files there is the text that is included in the help.
e) the support list. Plenty of helpful people there
The problem, I think, is not only to go from IBX to IBO, but to go from "paradox" mentality to Client/server. Understanding the Client/server aproach is the more difficoult step. Once you get that, you wonder how you could ever build an true C/S app with components like IBX.
And about RAD and time save: IBO native components have a pretty different aproach with the (native) visual components: lot of visual thing is defined in the query, not in the component. At first it seems bad, but once you get the idea it reveals to be very effective (and you can often override them at component level too). And consider this: my database has a big use of domains. In the connection component I define a lot of attributes for domain that are used by all fields of that domain. Then all the queries of my app automatically inheret them! So I've all date edit and display mask defined, and so for currency ones, uppercase when required, and so on. And if I want to change something.. whell, I have to change it only in one place, and for all the app. In addition, IBO can get fields default value from the server (in a very effective way in the 4.2Gc version), so I can have to define/change only in the database, without having to touch the client app, or worring about they!
going out of sync.
And this just to name few...
Regards
Marco Menardi
Community email addresses:
Post message: IBDI@yahoogroups.com
Subscribe: IBDI-subscribe@yahoogroups.com
Unsubscribe: IBDI-unsubscribe@yahoogroups.com
List owner: IBDI-owner@yahoogroups.com
Shortcut URL to this page:
http://www.yahoogroups.com/community/IBDI
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>>> mmenaz@... 04/12/02 01:06PM >>>--- In IBDI@y..., "David Cornelius" <corneliu@o...> wrote:
> Hi Kevin,[CUT]
>
> What has helped you mostlearn IBO? The newsgroups? Just plain experience?
You have to:
a) read "getting started guide". It's cheap and very useful
b) study the samples that come with
c) understand that the help for a property of a component very often has to bee searched for the ancestor of that component, where is widely explained (at first I was complaining for the "scarne" help wondering where was the huge help content IBO people was talking about... it's there!)
d) read the source, Luke! In the *.INT (interface) files there is the text that is included in the help.
e) the support list. Plenty of helpful people there
The problem, I think, is not only to go from IBX to IBO, but to go from "paradox" mentality to Client/server. Understanding the Client/server aproach is the more difficoult step. Once you get that, you wonder how you could ever build an true C/S app with components like IBX.
And about RAD and time save: IBO native components have a pretty different aproach with the (native) visual components: lot of visual thing is defined in the query, not in the component. At first it seems bad, but once you get the idea it reveals to be very effective (and you can often override them at component level too). And consider this: my database has a big use of domains. In the connection component I define a lot of attributes for domain that are used by all fields of that domain. Then all the queries of my app automatically inheret them! So I've all date edit and display mask defined, and so for currency ones, uppercase when required, and so on. And if I want to change something.. whell, I have to change it only in one place, and for all the app. In addition, IBO can get fields default value from the server (in a very effective way in the 4.2Gc version), so I can have to define/change only in the database, without having to touch the client app, or worring about they!
going out of sync.
And this just to name few...
Regards
Marco Menardi
Community email addresses:
Post message: IBDI@yahoogroups.com
Subscribe: IBDI-subscribe@yahoogroups.com
Unsubscribe: IBDI-unsubscribe@yahoogroups.com
List owner: IBDI-owner@yahoogroups.com
Shortcut URL to this page:
http://www.yahoogroups.com/community/IBDI
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/