>>>>>>>I've got a little bit different but still associated with the above issue question. There's a user-entered field that should be unique. So, I use candidate index which is checked when user tries to save changes with tableupdate(). The bad thing is that deleted records are also checked unless I use filter for not deleted() (goodbye Rushmore :( ). The workaround that I see is to use two indices on that field (w/ and w/o filter).
>>>>>>>
>>>>>>>Does anybody have better solutions?
>>>>>>>
>>>>>>>Thanks in advance.
>>>>>>
>>>>>>You could use following solution:
>>>>>>1. You have candidate index (no filter).
>>>>>>2. When you try to save a record and trap duplicate key error, you can check >deleted() status of the existing record and, if deleted=.t., recycle it.
>>>>>
>>>>>Thanks, Edward. I tried that approach and here some of my thoughts:
>>>>>
>>>>>1. This works only with views. When I used table (ether with record or table buffering) I couldn't move record pointer to check if the record with the same field value is deleted. The error "The uniqueness of ...bla,bla,bla violated" occured when I tried to do that.
>>>>>
>>>>>2. What if user doesn't add a record but changes the existing one? How do I recycle the deleted record? I tried to REPLACE the unique field of the deleted record with the STR(primary key)(I use surrogate Integer keys) of that record, assuming that the field is a string and user can't put numbers in it. So the value would be unique.But it won't work with numeric fields.
>>>>>
>>>>>Thanks, again.
>>>>
>>>>Didn't you know that I don't use buffering?
>>>
>>>I didn't know that when I wrote my message. Now I know that you don't use variables eather. Could you explain your approach to editing data in detail?. Do you always use views?
>>>
>>>>BTW, VFP6 will have function allowing SEEKing without moving pointer. In regard >to second problem: it's not difficult to have routine finding new 'unique' key >value to shift out deleted record. BTW, the normal process could also involve >'safe deletion': when you delete a record, candidate key values get replaced by >some reserved sequence (e.g. "000001","000002", etc.).
>>>
>>>I thought about it. The problem is you can't do it in Delete Trigger (the natural place to do it). So I'll lack flexibility using my own delete routine.
>>>Also, as I said before it won't work with numeric fields if user can type any numeric value (even negative).However it's a rather rare case.
>>>
>>>>Privet Sevastopolyu.
>>> :) Spasibo. I vam zdraste.
>>
>>I don't use memory variables. Instead of this, I use PEMs and unbound controls, i.e. any form (class) has generic custom method which populate Control.Value or Caption, etc. properties by field values. When it's ready to save, another code Insert or Replace field values from control properties.
>
>Edward-
>I like this approach a lot because of the advantage of being able to use INSERT from.
>However, I have yet to implement anything like it becuase of the huge increase in code it would require (the way that I understand you do it). To save work while using this approach, I am trying to put together some classes that would take care of everything without custom code in every form. My ideas are as follows:
>Textboxes, spinners, lists, etc., have a custom property called datafield. This property is filled at design time with the value that would normally reside in controlsource. There is another property called editmode. (This is toggled in the add/edit/save/undo methods, just like form.editmode. The controlsource property is left empty. The refresh event of the classes:
>
>this.value = eval(this.datafield)
>
>In the form's add, edit, save undo methods, I would have code that would loop through the controls and set memvars to their values according to the datafield values, insert from (or replace, or whatever) them and release them. I am far from having the details and complete concepts worked out, but I wondered if you have similar (in concept) classes working for you, and if so, how did you approach it? I am very interested to hear the nuts and bolts of how your forms work. Thanks.

Basically, I have very flexible multiple-form interface using however just one default session. I think that using buffering once we already committed to use private data sessions for each form and btw it will take additional coding. Having just one default session, I can handle network/multiuser problems in much more reliable way. My forms actually don't care how you leave them switching to another form. The only thing they have to have is custom recordpointer property, which stores current record pointer of the 'form master' alias. Custom method filling all control.value should be fired from Form.Activate event only in case if record pointer when we return to the form is not the same, so form should be 'refreshed'. The same method will be fired by navigation buttons. BTW, I never show users the message 'You reached the end of file'. Instead of this the same method enables/disables navigation buttons making SKIP/SKIP -1 test, which is also would be difficult having row buffering.