Doctor, it hurts when I do that.
Don't DO THAT.
Seriously the insert command to physically insert a record in the middle of a dbf has been obsolete since Foxbase.
It is horribly slow and locks the entire table while attempting to move all the records around.
Use append blank or a sql insert.
If you need to return records in a particular order, that what indexes and select statements are for.
Just in case people think I am on my soapbox again, here is the VFP Hacker's Guide entry for Insert. (Boy its crowded on top of this soap box.)
INSERT adds records to the current table at the current record pointer position. INSERT is almost always a bad idea. This command is part of FoxPro's Xbase legacy and generally leads to bad code. In all our experience, we've only found one situation where using INSERT was a good idea—more on that below.
Don't confuse this INSERT command with the SQL INSERT command, which is very useful.
Usage INSERT [ BLANK ] [ BEFORE ]
Used by itself, INSERT is much like APPEND by itself, but requires exclusive access. It adds a record and brings up an EDIT-type window to fill in the fields. The fly in the ointment is that the new record is physically inserted immediately following the current record. This means that every record following that position has to be physically moved to make room. On a large table, INSERT is a spectacularly bad choice.
Adding the BLANK keyword is like using the BLANK keyword of APPEND. The new record is added behind the scenes and there's no interaction.
The BEFORE keyword indicates that the new record should precede rather than follow the current record.
If the table has any open indexes (even if order is set to 0), the new record is added at the end, whether or not you specify BEFORE. This actually makes it a better command than it is otherwise, but also makes it obsolete since you can do the same thing with APPEND.
INSERT can't be used with most of the cool stuff in Visual FoxPro. You can't INSERT in a buffered table, or in one that has rules, triggers, primary keys or candidate keys.
INSERT respects SET CARRY, bringing forward values from specified fields when CARRY is ON.
So, what about the one time we've found INSERT useful? The situation was a very small table (never more than a couple of hundred records), which was to be copied out to an SDF file, from which it would be sent to the printer. The record order was essential to the reporting process. Because the result might be more than one page, we needed to insert a record containing a page feed character after every 54 records. INSERT was just the ticket. The moral, though, is the situation has to be pretty unusual before it's worth using INSERT.
See Also Append, Insert-SQL, Set Carry
Copyright © 1998 by Tamar E. Granor and Ted Roche. All Rights Reserved.