Hi Friends,

I am just now moving onto XBASE++ from Clipper 5.0.

I have come across a problem with COMMIT command, this command is slowing
down my sw drastically.

pls help.

Regards,
Husain Salik

Xbase++ does a commit on Unlock ie it is no longer needed to do this

COMMIT
UNLOCK

just do

UNLOCK

This may help some

Jim

Husain Salik wrote:
> Hi Friends,
> 
> I am just now moving onto XBASE++ from Clipper 5.0.
> 
> I have come across a problem with COMMIT command, this command is slowing
> down my sw drastically.
> 
> pls help.
> 
> Regards,
> Husain Salik
> 
>

Hello James

How do you know ?

> Xbase++ does a commit on Unlock ie it is no longer needed to do this
>
> COMMIT
> UNLOCK

Best Regards
Osvaldo Ramirez

James,
    From the STD.CH include file from clipper
       #command COMMIT                 => dbCommitAll()

the UNLOCK would have to have been done prior
to the COMMIT command or the COMMIT command
would produce an error.  COMMIT was a way of
flushing the buffers and forcing a write back to the
database file.  Isn't that right?
- Randy Howe


"James Loughner" <jwrl@charter.net> wrote in message 
news:3c46e31e$65de3c24$1a306@news.alaska-software.com...
> Xbase++ does a commit on Unlock ie it is no longer needed to do this
>
> COMMIT
> UNLOCK
>
> just do
>
> UNLOCK
>
> This may help some
>
> Jim
>
> Husain Salik wrote:
>> Hi Friends,
>>
>> I am just now moving onto XBASE++ from Clipper 5.0.
>>
>> I have come across a problem with COMMIT command, this command is slowing
>> down my sw drastically.
>>
>> pls help.
>>
>> Regards,
>> Husain Salik
>>
>>

An Unlock does a Commit in Xbase++, unlike Clipper. So doing an Unlock
and commit is redundant and may cause two writes. How do I know Stephen
told me

Jim

Randy Howe wrote:
> James,
>     From the STD.CH include file from clipper
>        #command COMMIT                 => dbCommitAll()
> 
> the UNLOCK would have to have been done prior
> to the COMMIT command or the COMMIT command
> would produce an error.  COMMIT was a way of
> flushing the buffers and forcing a write back to the
> database file.  Isn't that right?
> - Randy Howe
> 
> 
> "James Loughner" <jwrl@charter.net> wrote in message 
> news:3c46e31e$65de3c24$1a306@news.alaska-software.com...
>> Xbase++ does a commit on Unlock ie it is no longer needed to do this
>>
>> COMMIT
>> UNLOCK
>>
>> just do
>>
>> UNLOCK
>>
>> This may help some
>>
>> Jim
>>
>> Husain Salik wrote:
>>> Hi Friends,
>>>
>>> I am just now moving onto XBASE++ from Clipper 5.0.
>>>
>>> I have come across a problem with COMMIT command, this command is slowing
>>> down my sw drastically.
>>>
>>> pls help.
>>>
>>> Regards,
>>> Husain Salik
>>>
>>>
> 
>

James,

> An Unlock does a Commit in Xbase++, unlike Clipper. So doing an Unlock
> and commit is redundant and may cause two writes. How do I know Stephen
> told me

In Clipper v5.x, dbUnlock() caused an implicit commit.

COMMIT is a legacy command in network apps, but is very important when the
file is used exclusively as writes are cached, and the cache may not be
flushed when the file is closed, so updates can easily be lost.

Clipper S'87 required COMMIT, and many C'5.x apps are S'87 source
recompiled, so it is necessary to have the command both for exclusive use
and compatibility with Clipper.

Regards,

Phil Ide

-----------------------------------------------------------------
xbHCL (http://www.xbHCL.com)     Xbase++ HTML command layer
PBIH  (http://www.pbih.eu)       Polar Bear International Hosting
-----------------------------------------------------------------
Xbase++ FAQ, Libraries and Sources:
http://www.idep.org.uk/xbase

And don't dangle your participles in public.

"Husain Salik" <husainsalik@yahoo.com> wrote:

I have found that xbase DOES NOT do a commit after Unlock, I  use the
following Logic, and it does work.

When I put the Commit inside the loop, processing of a few hundred
records took 4 minutes, as shown below it was around 20 seconds  

DO WHILE ????

    Rlock()
    DO SOME STUFF
   UNLOCK

   SKIP
ENDDO

COMMIT


>Hi Friends,
>
>I am just now moving onto XBASE++ from Clipper 5.0.
>
>I have come across a problem with COMMIT command, this command is slowing
>down my sw drastically.
>
>pls help.
>
>Regards,
>Husain Salik
>

Strange Stephen told us at the DEVCON that an unlock does perform a
commit. Or did I imagine that? :

Jim

Geoffrey Cohen wrote:
> "Husain Salik" <husainsalik@yahoo.com> wrote:
> 
> I have found that xbase DOES NOT do a commit after Unlock, I  use the
> following Logic, and it does work.
> 
> When I put the Commit inside the loop, processing of a few hundred
> records took 4 minutes, as shown below it was around 20 seconds  
> 
> DO WHILE ????
> 
>     Rlock()
>     DO SOME STUFF
>    UNLOCK
> 
>    SKIP
> ENDDO
> 
> COMMIT
> 
> 
>> Hi Friends,
>>
>> I am just now moving onto XBASE++ from Clipper 5.0.
>>
>> I have come across a problem with COMMIT command, this command is slowing
>> down my sw drastically.
>>
>> pls help.
>>
>> Regards,
>> Husain Salik
>>
>

Geoffrey Cohen <geoff@rce.com.au> wrote in 
news:clf5c2tl2u940lce22jf8m2o67fn2ppm0q@4ax.com:

> When I put the Commit inside the loop, processing of a few hundred
> records took 4 minutes, as shown below it was around 20 seconds  
> 
> DO WHILE ????
> 
>     Rlock()
>     DO SOME STUFF
>    UNLOCK
> 
>    SKIP
> ENDDO
> 
> COMMIT

I received the same information, and I believe there are some past 
threads on this issue in the newsgroups.

if the commit is inside the loop, the function is doing extra work.. so i 
would expect it to be slower..  

I wrote a specific function my_unlock() to make it easier control unlock 
behavior depending on what comes up in the future, but we're happy with 
the results of eliminating the commits.  It's not empirical, but things 
seems more stable this way.

Brian

This is with 1.82, of course


>Geoffrey Cohen <geoff@rce.com.au> wrote in 
>news:clf5c2tl2u940lce22jf8m2o67fn2ppm0q@4ax.com:
>
>> When I put the Commit inside the loop, processing of a few hundred
>> records took 4 minutes, as shown below it was around 20 seconds  
>> 
>> DO WHILE ????
>> 
>>     Rlock()
>>     DO SOME STUFF
>>    UNLOCK
>> 
>>    SKIP
>> ENDDO
>> 
>> COMMIT
>
>I received the same information, and I believe there are some past 
>threads on this issue in the newsgroups.
>
>if the commit is inside the loop, the function is doing extra work.. so i 
>would expect it to be slower..  
>
>I wrote a specific function my_unlock() to make it easier control unlock 
>behavior depending on what comes up in the future, but we're happy with 
>the results of eliminating the commits.  It's not empirical, but things 
>seems more stable this way.
>
>Brian
>
>