Records don't truly exist in the database until they are committed.

Commit points are governed by two things:

1. What is the logical unit of work for the task at hand? Typically,
this is one complete business transaction, which will cover a few
rowsacross several tables.

2. When a large number or rows must be inserted, as in a migration,
where is the best balance between performance and recoverability? I
find commit points somewhere between between 1000 and 5000 rows per
transaction works well for this sort of application.

On Fri, 2005-06-10 at 13:26 +0200, Ivan Prenosil wrote:
> >> One should or shoudn't commit after a bunch of records ?
>
> I would still like to know whether people commit after a bunch
> of records because they were told to do so, or whether it really
> solved some insert speed problems.
> And whether they investigated whether slow insert was caused
> by application or fb server (and if by fb server, under which conditions)?
>
> (I am asking because I never noticed such problems myself.)
>
> Ivan
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://firebird.sourceforge.net and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Yahoo! Groups Links
>
>
>
>
>
>