The main change from Paradox/BDE to IB/IBO is to stop transferring entire
tables in grids and start asking the user to state exactly which
record/records he/she needs. Stored procedures are useful, but IB can work
satisfactorily without them unless you have demanding tasks to do.

BeginBusy prevents IBO from updating the screen cursor several times for
each insert/update, so it's no surprise that a bulk insert of 1000 records
is slow if you don't call it.

Nice to see that you found out how to speed up your program!

Set

At 21:07 11.01.2001 -0000, you wrote:

>Hello:
>
>I understand that I have much to learn about IB and IBO. My initial
>thought was to do a conversion, get the database in IB format, get
>the applications back in service then start learning the finer points
>of IB and IBO. However, when the speed suffered to such a great
>degree, this plan seemed unfeasable. I realize this may be a stupid
>question but here goes anyway: I can understand in a client/server
>setup how you would want most of the data manipulation done on the
>server to minimize the amount of data being transfered to the
>client. So I can see how stored procedures etc. would be of useful.
>However, if the application is running as a single user application
>or on a local network, how would this make a difference in speed? By
>the way, someone posted an example caled Impreved.zip that uses
>beginbusy. I downloaded this example and it makes a dramatic
>difference in speed.
>
>Thanks
>
>--- In IBObjects@egroups.com, "Jason Wharton" <jwharton@i...> wrote:
>> I suggest that you learn how to use a stored procedure which will
>handle
>> some of those fairly complex data manipulations. Instead of making
>IB
>> prepare a lot of separate statements you can make one stored
>procedure with
>> all the logic in it and then prepare it and send it the information
>it needs
>> and it will all execute on the server.
>>
>> This is the essence of the difference between PDOX and
>client/server is that
>> much of the processing can now actually be transferred to the
>computer
>> instead of forcing it to happen from the client.
>>
>> Hang in there. People's criticisms of your approach should not be
>taken
>> personal. Bear with it because they are telling you things that will
>> eventually make you wonder how you tolerated using local file based
>database
>> systems.
>>
>> If you try and make InterBase do exactly what PDOX does then PDOX
>is going
>> to seem faster. But, the thing you need to do is come to understand
>where
>> IB's strengths are and how to tap into them. It is well worth the
>time and
>> energy you will expend.
>>
>> Regards,
>> Jason Wharton
>> CPS - Mesa AZ
>> http://www.ibobjects.com
>>
>>
>> ----- Original Message -----
>> From: <SLSolutions@a...>
>> To: <IBObjects@egroups.com>
>> Sent: Thursday, January 11, 2001 7:13 AM
>> Subject: [IBO] My final post about IB vs Paradox speed
>>
>>
>> > As a new Interbase/IBO user I made a post about the fact that my
>> > application accessed data much slower after converting to IB and
>> > asked for any help more advanced users could offer. Although, I
>did
>> > get a few attempts to help, most responses were about how silly my
>> > test was and defending the speed of Interbase and IBO.
>> >
>> > This is all nice but the fact is this: I have an accounting
>> > application that was written in DOS with Btrieve as the
>database. It
>> > has been running fine for about 10 years on hundreds of local
>> > networks. Several years ago, I converted the application to
>> > Windows/D5/Paradox. Again, it has been running fine except for
>the
>> > occasional index corruption by Paradox. When I heard about
>Interase
>> > and IBO I converted that application to D5/IB/IBO. The
>application
>> > ran fine but every module accedded that data much slower. I
>assumed,
>> > based on the many posts I had read about the speed of Interbase,
>that
>> > I had done something wrong.
>> >
>> > My initial conversion was using IBOTables. I assumed this could
>be
>> > the problem since I was not taking advantage of the full power of
>> > Interbase and IBO using this approach. So I took one module and
>did
>> > the conversion to IB_Querys etc.
>> >
>> > In this module, every time a new record is added, 3 support tables
>> > are updated. Two of the support tables have 12 records each added
>> > and the final support table gets 1 record added for a total of 25
>> > records added each time a record is added to the main table.
>> >
>> > In the Paradox version, this is instantaneous. The Save button is
>> > clicked, the records are added and control instantaneously
>returns to
>> > the user. In the Interbase version, there is a noticable lag.
>> >
>> > I then wrote a test program to add 1000 records to an interbase
>table
>> > and 1000 records to a Paradox table. The Interbase adds were
>> > significantly slower. I then posted the basics of the test
>program
>> > to see if someone could tell be what I was doing to cause this to
>be
>> > so slow. I never intended that this be interpreted as a "real
>life"
>> > application or an example of adding batch records. I simply
>thought
>> > someone would look at it and say "you need to do this" and my
>problem
>> > would be resolved.
>> >
>> > Instead, most posts were about how "silly" the test was, how no
>one
>> > would actually do this, etc. I did get a few usefull posts and
>made
>> > the suggested changes (Using Insert instead of Append, using
>INSERT
>> > INTO SQL using Parameters). Problem is, none of these increased
>the
>> > speed. I am fully aware that my test program is impractical
>since no
>> > one will probably add 1000 records to a file, however, my "real
>life"
>> > program does add 25 and IS significantly slower!!
>> >
>> > It was never my intent to imply that IB/IBO was slower than
>Paradox.
>> > I assumed, and still do, that something I am doing is causing the
>> > problem. I never intended my post to set off a frenzy of IB/IBO
>> > defenders.
>> >
>> > I made the initial post to the IBObjects group since the group
>states
>> > it is a place for both novice and experienced Interbase/IBO
>users. I
>> > have found that this group is probably not the best place for the
>> > novice user.
>> >
>> >
>> >
>> >
>> >
>
>
>
>
>