I am thinking of switching to undefined fields, that would solve it as I 
would only have to worry about the tcursor.


On 06/22/2018 06:09 PM, Steven Green wrote:
> 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.
>>
>