Barbara's suggestion is a great one.

As to me, it's not that I have any problems with tables in the default datasession, it's leaving them open cross-object. In your case, you have a table that is rarely if ever modified and the overhead of leaving it constantly opened is not really justified. Better to grab the record you need and then throw it into an object. :-)



>One can always count on you for good suggestions. I'll keep it in the tool kit.
>
>In this case, I might actually follow John Koziol's advice and not leave any open tables at all in the default datasession. I would add a property to the form on the fly to keep the old value. Is that good or bad OOP form? It is a simple form based on the first level form subclass. As you can see, I am trying to get develop good OOP habits. (Not to mention the right buzzwords...)
>
>Thank you.
>
>Alex
>
>
>>Hi, Alex,
>>Here's my $.02 US -- You can separate the two company values completely by using the sis.dbf with 'Again' --

>>USE sis.dbf again alias ComboSis

and setting your combo values to the ComboSis table. This way the record pointer on SIS never moves from the record stored in oSis, and as the user moves around in ComboSis you can save/revert/etc. without changing oSis at all.
>>
>>HTH
>>Barbara
>>
>>>Hi,
>>>
>>>I have a company table (sis.dbf) that had one row SCATTER NAME'd to an object oSis. Now the user is given the opportunity to select another company from a list in a form. The list comes from the same table. The question is, to what should I set the properties of the list: ControlSource, ColumnCount, ColumnWidths, FirstElement, RowSource, RowSourceType, etc.
>>>
>>>In order to allow the user the opportunity to change his mind and back out it seems that the ControlSource should be a properly initialized memory variable or property of the form, and not a property of the oSis object. What do you all think.
>>>
>>>TIA,
>>>
>>>Alex