append current record II

[Bob Arbuthnot]

Are there any advantages of using one over the other?

<TBL>.COPY_RECORD_TO()

vs

append.run("append_operation_name","recno() = " + table.current().recno() )

Consider an environment in which the receiving table has 1 million records and the from table has 100k records, networked.

ba

[G Gabriel]

Re: append current record II

If there is any advantage, it would be in terms of execution time and as they say, the proof is in the pudding. I'd run both and check for speed. And while you are at it, you could also test another one:

t=table.current()
t1=table.open("..target_table..")
t1.enter_begin()
t1.fiield1=t.field1
..etc..
t.enter_end(.t.)
t.close
t1.close()

Or, another one:

<TBL>.RECORD_DATA_GET()
<TBL>.RECORD_DATA_SET()

Or, another one:
<TBL>.RECORD_CLONE()

Personally, and without checking speed, I common-sensically opt for:
table.open()
table.enter_begin()
etc.
as I assume all other "functions" are simply wrappers and include this routine in their guts.

P.S.
Something funny about speed I have yet to put my finger on: you could run a speed test on the same function under the same conditions and come up with different results. So, unless your results show "significant" difference, I wouldn't favor one or the other.

[csda1]

Re: append current record II

Hi Bob,

Are there any advantages of using one over the other?

<TBL>.COPY_RECORD_TO()

vs

append.run("append_operation_name","recno() = " + table.current().recno() )

Consider an environment in which the receiving table has 1 million records and the from table has 100k records, networked.

The reason Alpha can be simple and at the same time fast is they have created fast primitives that perform operations that are defined to have a large scope.

The append operation is one of these. Rather than copying 1 record at a time and repeating via XBasic (relatively slow versus a C type code) as in the copy record_to(), it does an append of many records. Depending upon your append options, the 1st thing it might do is perform a query of the source or destination tables. Make sure your filters will invoke LQO, otherwise you will be doing a slow query.

However, and this is a big one, the time to append a record when in a shared environment (using a non-client-server format like DBF) that has more than 2 or more current users/opens of the destination table, the append has to save 1 record at a time, updating the data and indexes, and this is relatively slow process.

The moment you are the only use of the table (not necessarily opened as exclusive), it switches to another mode. In this mode, it appends all the records quickly, then rebuilds the indexes at the end. If you have a lot of records and/or indexes, this rebuild of indexes can take a lot of time.

So if you want the 1st case to occur, you make sure there are 2 opens of the same table in the code.

The record append part of the append operation should always be faster than the record copy (except possibly for a small number of record copies), but the speed will be based upon the overhead of any initial queries and if there is an index rebuild.

[G Gabriel]

Re: append current record II

Ira:
He is talking about one record, not several.

[Bob Arbuthnot]

Re: append current record II

Thanks, G, for the thoughtful response and some other alternatives.

So, Ira, does the <TBL>.COPY_RECORD_TO() rebuild indexes if there is only one instance of the destination table open?

ba

[csda1]

Re: append current record II

Hi Bob,

..does the <TBL>.COPY_RECORD_TO() rebuild indexes if there is only one instance of the destination table open?

No. <TBL>.COPY_RECORD_TO() merely does an enter of an entire record in the destination table, resulting in some field rules being applied and an update to the index file with that record (just as an enter might).

What Gabe said about the others methods being wrapper-type functions is incorrect. A record get/set/clone etc work on the entire record, as opposed to individual fields, and are not XBasic code.

Alpha 5 methods (as opposed to functions) are never (as far as over 10 years of use and testing indicate) written in XBasic code, and are typically as fast as they could be given what they need to do.

[G Gabriel]

Re: append current record II

In the end, all roads lead to Malta, question is which one is the fastest.
Any speed tests yet?

[G Gabriel]

Re: append current record II

Bob:

So, Ira, does the <TBL>.COPY_RECORD_TO() rebuild indexes if there is only one instance of the destination table open?

For some reason, Ira did not answer your question, so I will answer it:
Yes it will re-build indexes, and if it does not, it should and that will happen regardless of what method you use.

If you are looking for a method that will bypass the indexes: first you won't find one and second, if you find it do not use it.

If you are looking for better performance, the answer is not to use some function or method that will not rebuild the indexes but rather to avoid indexes as much as possible.

[csda1]

Re: append current record II

For some reason, Ira did not answer your question, so I will answer it:
Yes it will re-build indexes, and if it does not, it should and that will happen regardless of what method you use.

I did answer the question. It does not rebuild indexes, it merely adds the new record to an index as any new Record being entered to a table does at save time (which adds exactly 1 index entry to each index that needs to be updated, a Btree structure, taking typically less than 1 millisecond on a typical network)

An Index rebuild deletes all indexes attached to the table and rebuilds the btree structure for every record in the table, not the 1 record being saved.

This has been true for all DBF file formats since the beginning of the DBF format!