if you know you made changes, postrecord should be the correct option.. but 
if you haven't made changes, testing the true/false result gives an error.. 
and, as you said, enumlocks creates one itself, so you never know if you 
already had one or not.. that's why it's called "paradox" :-)

I fight with stuff that people have done, that forces locks on linked 
tables, all the time.. pdoxwin is much more problematic, in that regard, 
than pdoxdos.. linking on indexed fields, instead of real key fields, 
creates massive nightmares

--

Steven Green
Myrtle Beach, South Carolina, USA

http://www.OasisTradingPost.com

Collectibles and Memorabilia
Vintage Lego Sets and Parts
- and Paradox support, too
"Peter"  wrote in message news:5b2d49b6$1@pnews.thedbcommunity.com...

I'm finding the "unposted" part is a problem.

I put in this code to ensure data has been posted
if not tc.unLockRecord(0 then
    errorShow()
endIf
However that generates an error if the the tc does not have a lock.

I try to test for a lock using tc.recordStatus("Locked") but that does
not show locks placed by Pdox. So the only way I see of testing for any
locks is to use tc.enumLocks() and then open yet another tcursor, on the
answer tbl to see if there are any record locks.

I am wondering if there is an acknowledged routine to test for any/all
locks on a record, explicit or by Pdox.


On 06/22/2018 05:58 AM, Mark Bannister wrote:
> Currrecord() can cause data loss if there is really and uposted record.
>
> On 6/21/2018 8:30 PM, Peter wrote:
>> Hmm, been doing some thinking and observing since I posted this question.
>>
>> It seems that the problem is only the last defined field that has been 
>> changed and focus remains on the field, ie not departing.
>>
>> The button I click has TabStop property set to False so focus would not 
>> leave the field and therefore the record would be locked by Pdox? But the 
>> status bar does not have a "Locked" mssg.
>>
>> So if that were the case maybe all I have to do is find out which field 
>> has focus and issue an unlockRecord()?
>>
>> Update:
>> Well that didn't work either
>>
>> I used a tc.currRecord()and that seems to have solved the problem so far.
>>
>> I have no idea why the table and the tcursor cannot sync up with resync, 
>> nor why the tcursor is not up to date when I issue an unlock.
>>
>> On 06/21/2018 12:50 PM, Peter wrote:
>>> I have been fighting a stubborn issue of not being able to post/unlock a 
>>> record. Finally found the problem and have been able to make a fix but 
>>> it is clumsy and I hope someone can provide an alternative.
>>>
>>> I have a form and several tables in the datamodel. The one table (call 
>>> it tableA) at issue is not linked.
>>>
>>> Several fields on the form are defined from tableA
>>>
>>> I use a tc.dmAttach("TableA") to make changes to records as well as 
>>> unlocking. The problem I ran into is that after unlocking the data would 
>>> not post to the table.
>>>
>>> I tried TableA.dmResync(tc) - did not solve the problem
>>> I tried dmResync(TableA,tc) - did not solve the problem
>>> I tried field.unlockRecord (using one of the defined fields)and that 
>>> worked when that field had been changed.
>>>
>>> I then tried field.unlockRecord() for all defined fields and that 
>>> worked, as such:
>>> field1.unlockRecord()
>>> field2.unlockRecord()
>>> field3.unlockRecord()
>>> field4.unlockRecord()
>>> more...
>>> tc.unlockRecord()
>>>
>>> What seems to happen is that if a defined field's value has been changed 
>>> then it needs a distinct unlock/post record
>>>
>>> So, is there a way to unlock all the define fields of a single table (in 
>>> the datamodel) in one statement instead of independantly?
>>>
>>> ps I also put a self.unLockRecord() in the :depart: method of each 
>>> defined field and that worked also, again clumsy I think.
>