FUNCTION qsaveiss(thisvar)
    do while .t.
        //rlock() - why double ?????
        if rlock()
            replace issued with thisvar
            unlock
            commit
            exit
        endif
    enddo
    return .t.

Z powazaniem/Best regards
Adrian Wykrota
www.advantec-software.pl
Uzytkownik "Chris Palmer" <clp1000@btopenworld.com> napisal w wiadomosci 
news:6ZLydNwrFHA.2944@S15147418...
Can somebody please explain to me why the following procedure returns this :
a
x
x
when it should be
a
a
a
because I've changed the field to "a"

Is there something wrong with the commit command???  Please noe that I am 
running an older version of Alaska
Thanks


procedure p_test

close all
use policy index i_poly  via foxcdx new
select policy

clear
seek 450001

qsaveiss("a")

? issued

thisref = ref
seek thisref

? issued

for qwait = 1 to 500000
next

? issued

qsaveiss("x")    ///This is only here to reset the field for this test

return


FUNCTION qsaveiss(thisvar)
    do while .t.
        rlock()
        if rlock()
            replace issued with thisvar
            unlock
            commit
            exit
        endif
    enddo
    return .t.

Adrian,

> FUNCTION qsaveiss(thisvar)
>     do while .t.
>         //rlock() - why double ?????
>         if rlock()
>             replace issued with thisvar
>             unlock
===>
>              commit - why double ????? 
===>
>             exit
>         endif
>     enddo
>     return .t.

Unlock performs an implicit commit.

BTW, Chris probably changes index order without realizing.

Regards,
Frans Vermeulen

> Is there something wrong with the commit command???  Please noe that I am
> running an older version of Alaska

Chris:
If it's a post 1.0 version there should be no problems doing anything like
this,
it must be a programming logic error, but that's hard to tell with this
little information.

Frans Vermeulen wrote:

>> Is there something wrong with the commit command???  Please noe that I am
>> running an older version of Alaska
> 
> Chris:
> If it's a post 1.0 version there should be no problems doing anything like
> this,
> it must be a programming logic error, but that's hard to tell with this
> little information.

To add one thing... a ready-to-run sample would help quite a bit. Funny
enough, sometimes while preparing such a sample, I found the cause of a
problem myself - most of the time a coding error 

Thomas

On Thu, 1 Sep 2005 17:23:19 +0200, Frans Vermeulen wrote:

> Unlock performs an implicit commit.

Hi Frans,

Where is that documented ?

Hope you are doing well,

Raymond Fischbach
Belgium
http://www.mouches.org

Raymond,

> > Unlock performs an implicit commit.
> 
> Hi Frans,
> 
> Where is that documented ?

It is not. Andreas Herdt told us at the XXP meeting last june.
 
> Hope you are doing well,

Yes I am, thnx, I had 3 company relocations last 2 months,
will move location of work myself again next month. 
Working hard, little money, you know IT 

Regards,
Frans Vermeulen

Frans, Raymond,

>>> Unlock performs an implicit commit.
>> 
>> Hi Frans,
>> 
>> Where is that documented ?
> 
> It is not. Andreas Herdt told us at the XXP meeting last june.

Incidentally, that also makes it compatible with Clipper, which also
performed an implicit commit on unlock.

Regards,

Phil Ide

*******************************************
*   Xbase++ FAQ, Libraries and Sources:   *
*   goto: http://www.idep.org.uk/xbase    *
* --------------------------------------- *
* www.xodc.org.uk - openSource Dev-Center *
*******************************************

If at first you don't succeed, cry.

Phil,

> Frans, Raymond,
>
>>>> Unlock performs an implicit commit.
>>>
>>> Hi Frans,
>>>
>>> Where is that documented ?
>>
>> It is not. Andreas Herdt told us at the XXP meeting last june.
>
> Incidentally, that also makes it compatible with Clipper, which also
> performed an implicit commit on unlock.
>

And finally, assuming a shared table, wouldn't it be an error if an implicit 
commit was not done on a unlock.  In fact the implicit commit should occur 
prior to the unlock; what right do you have to update a row that is 
unlocked?  Otherwise, how could a shared table ever have integrity in the 
classic account balance transaction problem.  Without the implicit commit, 
an unlock would need to behave as a rollback if there are uncommited changes 
thereby requiring an explicit commit for every row update.  (This is an 
example of concurrency theory)

While I believe that even the obvious should be clearly documented, the 
example code on the unlock documentation shows a row being deleted without 
an explicit commit.  Hence, using the above information and believing that 
Xbase++ is not critically flawed, the implicit commit on unlock is 
indirectly documented.

dbcommit() is useful for two things -

In a shared table situation, to expose row changes to other readers without 
releasing the lock.
In an exclusive table situation, to force the row changes from the DBE cache 
to the OS cache to ensure recording in the event of abnormal termination of 
the application.

Rodd

Rodd,

> And finally, assuming a shared table, wouldn't it be an error if an
implicit

Oopssss, forgot to mention this....
This is only the case with shared tables.
Thanks for catching this slip of the pen.

> dbcommit() is useful for two things -
>
> In a shared table situation, to expose row changes to other readers
without
> releasing the lock.

Correct.

> In an exclusive table situation, to force the row changes from the DBE
cache
> to the OS cache to ensure recording in the event of abnormal termination
of
> the application.

IIRC, Wrong, in an exclusive table situation, the OS determines when changes
are written to disk. Under WinXP it has to pass 5 caches (check that
yourself)
so it's highly improbable changes will ever make it to your disk.

Regards,
Frans Vermeulen

Frans,

>> In an exclusive table situation, to force the row changes from the DBE
> cache
>> to the OS cache to ensure recording in the event of abnormal termination
> of
>> the application.
>
> IIRC, Wrong, in an exclusive table situation, the OS determines when 
> changes
> are written to disk. Under WinXP it has to pass 5 caches (check that
> yourself)
> so it's highly improbable changes will ever make it to your disk.

Which is why I originally stated that it only commits the row changes from 
the DBE cache to the OS cache.  This only helps in the event of failure of 
the XBase++ program.  I have used commits in exclusive tables during key 
processes so that the process could be restarted after a non-recoverable 
runtime error (of the application, not OS) with minimum data loss.

Rodd

"Frans Vermeulen" <fransv@visspec.nl> wrote in message 
news:X7aAyK9rFHA.6792@S15147418...
> Rodd,
>
>> And finally, assuming a shared table, wouldn't it be an error if an
> implicit
>
> Oopssss, forgot to mention this....
> This is only the case with shared tables.
> Thanks for catching this slip of the pen.
>
>> dbcommit() is useful for two things -
>>
>> In a shared table situation, to expose row changes to other readers
> without
>> releasing the lock.
>
> Correct.
>
>> In an exclusive table situation, to force the row changes from the DBE
> cache
>> to the OS cache to ensure recording in the event of abnormal termination
> of
>> the application.
>
> IIRC, Wrong, in an exclusive table situation, the OS determines when 
> changes
> are written to disk. Under WinXP it has to pass 5 caches (check that
> yourself)
> so it's highly improbable changes will ever make it to your disk.
>
> Regards,
> Frans Vermeulen
>

So how can I solve the problem ???

"Adrian Wykrota" <a.wykrota@asitc.pl> wrote in message
news:rlS1lWwrFHA.3104@S15147418...
> FUNCTION qsaveiss(thisvar)
>     do while .t.
>         //rlock() - why double ?????
>         if rlock()
>             replace issued with thisvar
>             unlock
>             commit
>             exit
>         endif
>     enddo
>     return .t.
>
>
> -- 
>
> Z powazaniem/Best regards
> Adrian Wykrota
> www.advantec-software.pl
> Uzytkownik "Chris Palmer" <clp1000@btopenworld.com> napisal w wiadomosci
> news:6ZLydNwrFHA.2944@S15147418...
> Can somebody please explain to me why the following procedure returns this
:
> a
> x
> x
> when it should be
> a
> a
> a
> because I've changed the field to "a"
>
> Is there something wrong with the commit command???  Please noe that I am
> running an older version of Alaska
> Thanks
>
>
> procedure p_test
>
> close all
> use policy index i_poly  via foxcdx new
> select policy
>
> clear
> seek 450001
>
> qsaveiss("a")
>
> ? issued
>
> thisref = ref
> seek thisref
>
> ? issued
>
> for qwait = 1 to 500000
> next
>
> ? issued
>
> qsaveiss("x")    ///This is only here to reset the field for this test
>
> return
>
>
> FUNCTION qsaveiss(thisvar)
>     do while .t.
>         rlock()
>         if rlock()
>             replace issued with thisvar
>             unlock
>             commit
>             exit
>         endif
>     enddo
>     return .t.
>
>

"Chris Palmer" <clp1000@btopenworld.com> wrote in message 
news:TcujMG7rFHA.2944@S15147418...
> So how can I solve the problem ???

It's hard to understand what you intend, as you use fields without any 
alias, and some referances, such as "thisref" and "ref" are not defined in 
the code.

Maybe changing thisref = ref to thisref = issued would help?

So how can I solve the problem ???

"Adrian Wykrota" <a.wykrota@asitc.pl> wrote in message
news:rlS1lWwrFHA.3104@S15147418...
> FUNCTION qsaveiss(thisvar)
>     do while .t.
>         //rlock() - why double ?????
>         if rlock()
>             replace issued with thisvar
>             unlock
>             commit
>             exit
>         endif
>     enddo
>     return .t.
>
>
> -- 
>
> Z powazaniem/Best regards
> Adrian Wykrota
> www.advantec-software.pl
> Uzytkownik "Chris Palmer" <clp1000@btopenworld.com> napisal w wiadomosci
> news:6ZLydNwrFHA.2944@S15147418...
> Can somebody please explain to me why the following procedure returns this
:
> a
> x
> x
> when it should be
> a
> a
> a
> because I've changed the field to "a"
>
> Is there something wrong with the commit command???  Please noe that I am
> running an older version of Alaska
> Thanks
>
>
> procedure p_test
>
> close all
> use policy index i_poly  via foxcdx new
> select policy
>
> clear
> seek 450001
>
> qsaveiss("a")
>
> ? issued
>
> thisref = ref
> seek thisref
>
> ? issued
>
> for qwait = 1 to 500000
> next
>
> ? issued
>
> qsaveiss("x")    ///This is only here to reset the field for this test
>
> return
>
>
> FUNCTION qsaveiss(thisvar)
>     do while .t.
>         rlock()
>         if rlock()
>             replace issued with thisvar
>             unlock
>             commit
>             exit
>         endif
>     enddo
>     return .t.
>
>

I run your sample but i haven't your data file - and my results is
a
a
a

procedure main

IF DbeLoad( "FOXDBE", .T.)
  IF DbeLoad( "CDXDBE", .T.)
    IF DbeBuild( "FOXCDX", "FOXDBE", "CDXDBE" )
    ENDIF
  ENDIF
ENDIF

close all
dbcreate("policy", {{"ISSUED", "C", 1, 0}}, "FOXCDX")
//use policy index i_poly  via foxcdx new
use policy via foxcdx new
index on issued to i_poly
select policy
append blank

clear
//seek 450001

qsaveiss("a")

? issued

//thisref = ref
//seek thisref

? issued

for qwait = 1 to 500000
next

? issued

qsaveiss("x")    ///This is only here to reset the field for this test

sleep(100 * 5)

return


FUNCTION qsaveiss(thisvar)
    do while .t.
        //rlock()
        if rlock()
            replace issued with thisvar
            unlock
            commit
            exit
        endif
    enddo
    return .t.



Z powaaniem/Best regards
Adrian Wykrota
www.advantec-software.pl
Uytkownik "Chris Palmer" <clp1000@btopenworld.com> napisa w wiadomoci 
news:CqExIG7rFHA.6160@S15147418...
> So how can I solve the problem ???
>
> "Adrian Wykrota" <a.wykrota@asitc.pl> wrote in message
> news:rlS1lWwrFHA.3104@S15147418...
>> FUNCTION qsaveiss(thisvar)
>>     do while .t.
>>         //rlock() - why double ?????
>>         if rlock()
>>             replace issued with thisvar
>>             unlock
>>             commit
>>             exit
>>         endif
>>     enddo
>>     return .t.
>>
>>
>> -- 
>>
>> Z powazaniem/Best regards
>> Adrian Wykrota
>> www.advantec-software.pl
>> Uzytkownik "Chris Palmer" <clp1000@btopenworld.com> napisal w wiadomosci
>> news:6ZLydNwrFHA.2944@S15147418...
>> Can somebody please explain to me why the following procedure returns 
>> this
> :
>> a
>> x
>> x
>> when it should be
>> a
>> a
>> a
>> because I've changed the field to "a"
>>
>> Is there something wrong with the commit command???  Please noe that I am
>> running an older version of Alaska
>> Thanks
>>
>>
>> procedure p_test
>>
>> close all
>> use policy index i_poly  via foxcdx new
>> select policy
>>
>> clear
>> seek 450001
>>
>> qsaveiss("a")
>>
>> ? issued
>>
>> thisref = ref
>> seek thisref
>>
>> ? issued
>>
>> for qwait = 1 to 500000
>> next
>>
>> ? issued
>>
>> qsaveiss("x")    ///This is only here to reset the field for this test
>>
>> return
>>
>>
>> FUNCTION qsaveiss(thisvar)
>>     do while .t.
>>         rlock()
>>         if rlock()
>>             replace issued with thisvar
>>             unlock
>>             commit
>>             exit
>>         endif
>>     enddo
>>     return .t.
>>
>>
>
>