Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Insert blank before
Message
From
14/04/2012 15:46:21
Mike Yearwood
Toronto, Ontario, Canada
 
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
01541227
Message ID:
01541527
Views:
76
Some choose to call applying best practices gold plating. Conversely much of what I've seen is akin to using sh*t to plug a leak in a pipe.

The fact is INSERT BLANK BEFORE is already a JCB for cracking a nut AND it's a disgustingly poor nutcracker at that. It already exists, so reinventing the wheel would normally make me want to use it, but again, it was made by programmers who obviously did not design it for the real world, so it was deprecated. It is pig slow on anything but a miniscule set of records. I can't predict when it will become unusable by the user, but I rather find better techniques and thereafter use them anytime similar needs arise. You can attempt to have the cursor created on a local drive versus on the server, and then you are making INSERT BLANK BEFORE into an even bigger JCB to get around its performance limits.

OR

Recognizing that something is a bad practice, and ALWAYS avoiding it as such, you then should apply best practices. Create a single small method/procedure/udf/prg to encapsulate the best practice. If you are creating the temp cursor with sql, you add the sequence field at the same time, no harm, no foul. Obviously this cursor would be single user and exclusive and you can still place it on a local drive if you choose. The index is a no brainer. Updating every sequence number in this small cursor will always beat an INSERT BLANK BEFORE excepting possibly records added at the bottom of the cursor. There would be no gaps as you would again rely on a reusable method to generate the sequence.

Looking at the current record is a no-brainer as your user may already be sitting on it, so you really only need to look at 1 extra record, the one before the current one. You insert a record with the new number - rather than INSERT BLANK, so it's in place and ready.

With a large enough number of decimal places, you can expect to be able to insert a large number of records between any two, which will be an unbelievably quick procedure.

This practice then works for the tiniest set of records and for the largest set of records. One approach that handles far more situations is a better tool to have in your bag, that INSERT BLANK BEFORE.

>Hi Mike. So lets take an example of where there is a Temporary cursor, no idexes, and the eventual rowset is going to be small (say between 1-20 records) and the requirement is to insert a row in the midle:
>Method 1: Insert Blank Before
>
>Method 2.
>Create an extra field to be used as a Sequence field
>Create an Index
>Populate the Numeric field, with some arbitrary sequence, say leaving gaps
>Insert the Row ,as you sggest, if its between 2 and 3, use 2.5
>I then want to insert a row between 2 and 2.5 or 2.5 or 3, I have to start looing at previous or next Rows......
>
>Does nobody agree that method2 above is using a JCB to crack a nut, about 20 lines of code (and a fair bit of testing to ensure there are correct gaps if you are inserting multiple rows) .
>I agree that in the mainstream, for a live active database table, using an INSERT BLANK BEFORE is not the way to go, but for a temporary cursor maintanance with a small recordset, I remain to be convinced
>
>Regards,
>Gerard
>
>
>
>>Hi Gerard
>>
>>If it's a temporary cursor, you can easily add a numeric field with sufficient decimal points and an index. Then to insert between rows 2 and 3, insert a new record with 2.5. It will instantly sort into place. It's much faster than INSERT BLANK BEFORE. You can also dump these records to an array or cursor maintaining the sort. It will work with large or small data sets, so that's the technique I use every time such a request comes up.
>>
>>>Hi Koen.
>>>In this partcular case I would disagree with you.
>>>I am providing some additional functionality to an app that has already been designed.
>>>IN this partcular App, the Record Number is irrelevant. In a partcular form, I select records into a Temporary Table, and I want to insert a row
>>> in the middle, and then write them back out again with the inserted row in the middle. Unfortunately, the individual Rows do not have a 'Sequence number' so other than rewriting the complete app, I think that using INSERT BLANK BEFORE (Just on a temporary file) is a reasonable solution, in that Financial Considerations are important (i.e. the client will not pay for a full re-development)
>>>
>>>Regards,
>>>Gerard
>>>
>>>
>>>>Hi Gerard,
>>>>
>>>>Sorry but you are not correct: your application does not apply to rule #1 ( use index tags) and this rule is imperative!
>>>>The Exception you claim to find is incorrect. Never ever apply a table without an ID and an index.
>>>>I even believe it was a mistake of David not to make this default when he designed FP.
>>>>
>>>>Regards,
>>>>
>>>>Koen
>>>>++
>>>>
>>>>
>>>>
>>>>>Hi Tore.
>>>>>Generally I would agree with you, but I think there will ALWAYS be an exception . Indeeed, is'nt it the Exception always proves the rule !!
>>>>>In this partcular case, its an existing app with 1000's of lines of code, the Table thats being inserted against will never be more than 20/30 records and the customer requires an Insert option.
>>>>>The options are:
>>>>>1. Redesign completetrly the exisitng APP , intoduce indexes where thre were none , with a big chance of breaking it, and also investing perhaps 3 or 4 days in redeveloping and testing
>>>>>
>>>>>2. Introsuce about 5 lines of Code (INSERT BLANK BEFORE) being one of them, and as far as I can see this will do the job.
>>>>>
>>>>>I am inclined to go for Option 2.
>>>>>
>>>>>Regards,
>>>>>Gerard
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Rule # 1: Never make an application where the record number is important, use index tags instead.
>>>>>>Rule # 2: If the record number is important, rethink your design and see rule # 1.
>>>>>>Rule # 3: There are NO exceptions to these rules.
>>>>>>
>>>>>>>ok Sorted this.
>>>>>>>It appears that if the table has any index file associated (even though you have not Set Order to) , it always appends the row
>>>>>>>If all Indexes are removed from the table, it works fine
>>>>>>>
>>>>>>>
>>>>>>>>Hi.
>>>>>>>>I have a small basic DBF with a few fields and I want to insert a row
>>>>>>>>I position myself on the 3rd row OF 10
>>>>>>>>No indexes are on
>>>>>>>>
>>>>>>>>INSERT BLANK BEFORE
>>>>>>>>
>>>>>>>>but it appends a row at the end (i.e. 11th record instead of being the 2nd record)
>>>>>>>>I know I have done this in the past , but cant get it to work today.
>>>>>>>>What am I missing ?
>>>>>>>>
>>>>>>>>Tia
>>>>>>>>Gerard
Previous
Reply
Map
View

Click here to load this message in the networking platform