| Subject | Re: [IBO] Project size |
|---|---|
| Author | Helen Borrie |
| Post date | 2003-05-22T20:39:15Z |
At 08:12 PM 22/05/2003 +0200, you wrote:
You have a few issues here. First, when you had a BDE app you had two
large, separate libraries supplying the database connectivity, viz. the BDE
and the sqlint.dll driver. Now, with all of the connectivity actually
compiled into the exe, the memory usage will now pertain to the exe alone,
rather than to exe + BDE + driver, as occurred before.
Next, the TIBODataset components are actually TDataset components wrapping
internal TIB_BDatasets. Thus, you gain a little in runtime code because
the application is maintaining both TField objects and internal TIB_Column
objects. Ideally, you will eventually escape the burden of TField objects
and move over to the native TIB_ (although I know you told me it's not
practicable to do so much rework right now...)
Next, TIBOTables are not good for client/server use. The TIBOQuery has
almost as much functionality as the VCL's TIBOTable and it is much more
efficient and flexible than TIBOTable. A BDE-to-IBO conversion is fine for
getting you quickly into a running position with your old BDE project, but
it doesn't release you from the need to work towards more suitable
techniques for client/server work.
On the subject of stored procedures, seriously consider migrating away from
the storedproc component. Replace your selectable procedures with
TIBOQuery and your executable ones with TIB_Cursor or TIB_DSQL. About the
only advantage of the storedproc component is that it makes it (maybe) a
little easier to set up in the IDE. The downside is that you have a whole
heap of "stuff" in that component that can be treated much more lightly in
the client with the more efficient alternatives. Get used to using params
and you can sink all of those old barges - table and storedproc components.
regards,
Helen
(still pottering about in the magical city of Vienna)
>Hi,Hi Mieke,
>
>I have a Dephi 6 application. The size of the exe is about 8 Mb. The size of
>the firebird database file is about 90 Mb. When I don't use the
>IBObject-components the allocated memory of my application is about 60 Mb.
>Now, I migrated all my dbTables to IBODataset, all my Storedproc to
>IBOstoredprc, and so on. All of a sudden the allocated memory is 135 Mb!!!!!
>How is that possibel?
>
>Mieke Janson
You have a few issues here. First, when you had a BDE app you had two
large, separate libraries supplying the database connectivity, viz. the BDE
and the sqlint.dll driver. Now, with all of the connectivity actually
compiled into the exe, the memory usage will now pertain to the exe alone,
rather than to exe + BDE + driver, as occurred before.
Next, the TIBODataset components are actually TDataset components wrapping
internal TIB_BDatasets. Thus, you gain a little in runtime code because
the application is maintaining both TField objects and internal TIB_Column
objects. Ideally, you will eventually escape the burden of TField objects
and move over to the native TIB_ (although I know you told me it's not
practicable to do so much rework right now...)
Next, TIBOTables are not good for client/server use. The TIBOQuery has
almost as much functionality as the VCL's TIBOTable and it is much more
efficient and flexible than TIBOTable. A BDE-to-IBO conversion is fine for
getting you quickly into a running position with your old BDE project, but
it doesn't release you from the need to work towards more suitable
techniques for client/server work.
On the subject of stored procedures, seriously consider migrating away from
the storedproc component. Replace your selectable procedures with
TIBOQuery and your executable ones with TIB_Cursor or TIB_DSQL. About the
only advantage of the storedproc component is that it makes it (maybe) a
little easier to set up in the IDE. The downside is that you have a whole
heap of "stuff" in that component that can be treated much more lightly in
the client with the more efficient alternatives. Get used to using params
and you can sink all of those old barges - table and storedproc components.
regards,
Helen
(still pottering about in the magical city of Vienna)