>Hi Koen.
>No hard feelings at all and many thanks for yout contributions.
>Doctors differ and patients die ...

so they make and enforce standards to prevent that :)

Programmers differ and ......(fill in the blanks)

time and money are wasted and they go about patting themselves on the back for being dumb er clever enough to recreate the wheel, again. :)


>
>Regards,
>Gerard
>
>
>>Hi,
>>
>>I dont want to be nasty, nor picky, just wanted to make something clear. So without any hard feelings, I hope.
>>
>>you misunderstand me.
>>Rule # 1 is there should be an ID and an Index
>>your particular application is lacking of that. I would advise you to correct that first and from there on you can go-on.
>>
>>And your - the client will not pay for a full re-development - I agree, but I also have the opinion that clients should not pay for correction of mistakes and I call a table without ID and without an Index a clear mistake.
>>
>>However it seems you are satisfied with the found solution, so be it, I just wanted to make it clear to you that the solution you found is not to be progagandaded as being a nice generic one.
>>
>>Best regards,
>>
>>Koen
>>++
>>
>>>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