Trouble with foxpro locking scheme

[Tony Quick]

I need help tracking down a gremlin.  I'm having an occasional problem where my applications are freezing (or hanging) when adding or updating a new record.  It's extremely intermittent.  With about a dozen users, it' happens once or twice some days, and not at all on other days. It's different users and different DBF's.

The data is stored on a Netware 6.0 SP5 server. I have a mixture of Clipper and Harbour applications using the databases. Clipper version is 5.2 with Comix set to foxpro locking by linking cmxfox52.obj, and currently Harbour 3.2.0dev (r1501091819) using DBFCDX and foxpro locking. Also, the Clipper users are running Windows XP with Novell client, and the harbour users are mostly on Windows 7 64 bit with Novell client.

The reason I'm using Foxpro locking is there is one station running a VB6 application that uses Apollo Embedded with Foxpro locking to print a plastic ID card. (Apollo is from the same company that created the SIx RDD for Clipper 5.2) That application only uses one DBF file and does not use any of the files that have been involved in the freezes.

My harbour programs the following in rddsys.prg:

REQUEST DBFCDX, DBFFPT

INIT PROCEDURE RddInit
    RDDSetDefault( "DBFCDX" )
  SET DBFLOCKSCHEME TO DB_DBFLOCK_VFP
 
  Set( _SET_AUTOPEN, .t. )
  Set( _SET_AUTORDER, 0 )
  set( _SET_MFILEEXT, ".FPT" )
  set( _SET_OPTIMIZE, .T. )
RETURN  

I've narrowed the problem code to this sequence:

@ maxrow(),0 say 'Updating record...'
APPEND BLANK
IF ! neterr()
   REPLACE field with data /*various data fields with data */
   COMMIT
   UNLOCK
END IF

@ maxrow(),0 say 'done updating record!'

It freezes somewhere after the REPLACE statement but apparently when the index is being updated.  When I open the DBF, the newly created record is there with the correct data. But the record is not in the index. When I go to the new record, and SET ORDER TO 1 (or any other valid index order), ORDKEYVAL() returns NIL for the newly added record. Naturally, I end up rebuilding the indexes or else index corruption errors will appear.

I don't think the append blank is part of the problem because I had one case where a record could not be found after it was updated, and the reason turned out to be ORDKEYVAL() was returning the old key value.

Anybody have any ideas about what might be going on, and how to remedy this?

Thanks for reading this far,
Tony

[matt johnson]

I would flock() the file before append blank.

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elch]

Hi Tony,

we can assume, that concurrent locking generally works, right ?

You may check the Novell Client, i know that version for XP but not for Win7, and not NW6 ..

( on the 'N', right click, properties, extended properties: )

have there are at least two configuration points for file-caching (off) and file-commit (on)

best regards

Rolf

[Przemyslaw Czerpak]

On Fri, 06 Feb 2015, Tony Quick wrote:

Hi,

> I've narrowed the problem code to this sequence:
> @ maxrow(),0 say 'Updating record...'
> APPEND BLANK
> IF ! neterr()
> REPLACE field with data /*various data fields with data */
> COMMIT
> UNLOCK
> END IF
>
> @ maxrow(),0 say 'done updating record!'
>
> It freezes somewhere after the REPLACE statement but apparently when the
> index is being updated. When I open the DBF, the newly created record is
> there with the correct data. But the record is not in the index. When I go
> to the new record, and SET ORDER TO 1 (or any other valid index order),
> ORDKEYVAL() returns NIL for the newly added record. Naturally, I end up
> rebuilding the indexes or else index corruption errors will appear.

It means that application executing above code cannot lock index file
and it's frozen in infinite loop trying to lock it. At this moment you
should check on the server which station locked the index and then see
what it does. It's possible that it's turned off or lost the connection
to the server or process locking the index file died unexpectedly and
network redirector didn't inform the server about it or sth like that.
Anyhow the problem is outside Harbour.
BTW COMIX hyper locking is much more efficient then FOX PRO one so
I suggest to eliminate applications which needs it and change locking
scheme. You can create your own OLE server in Harbour with RPC functions
you can execute from VB and use it instead of Apollo. In HBWIN test
subdirectory you should find few examples of such servers I created
few years ago.

best regards,
Przemek Czerpak

[Tom Carpenter]

Since you are Appending a Blank record, you must also be entering data in the index key fields.  I've encountered a problem when updating the key fields of a "live" index.  The following has worked for me:

 

USE DBF  INDEX NTX

 

SET ORDER TO  0

APPEND BLANK

REPLACE   Key Fields  WITH  Stuff

 

SET ORDER TO  1

 

This seems to allow the index to update itself correctly without being the "live" index.  Typically when Appending a new record, the index does not need to be active at that moment, but all inactive indices are updated by the Replace command.  Once that happens, just make the index active again and everything is good.

 

Hope this helps.

 

Tom.

[Tony Quick]

Thanks for the help, but yeah, I made sure all the clients have caching off and commit on.

Tony

[Tony Quick]

Przemek,

Thanks for pointing me towards the OLE server idea.  I started using Apollo before I became aware of Harbour. I will certainly look at those examples.

I'm not aware of a way to see who has locks on indexes on a Novell network.  Do you know of a way?

Also, FWIW, I have had all other users who had the affected index open exit their programs, and even with only that one user still having the index open, the lock still did not succeed?  There's no indication that they have lost the connection to the server as other programs that have open are not having problems.  Is is possible that index corruption could have occurred previously, resulting in the apparent endless loop?

Regards,
Tony

[Tony Quick]

Przemek,

Sorry, but I forgot, there is a second application written in vb.net that uses Apollo.  AFAIK, in vb.net, the OLE server dll needs to have a type library embedded within.  I don't see a way to do that in harbour.  Is there a way to create a tlb for a harbour OLE server?

Tony

On Saturday, February 7, 2015 at 5:41:52 AM UTC-5, druzus wrote:

[Tony Quick]

The vb.net problem is resolved. The vb.net test application was set to x64 but harbour compiles to 32 bit ( x86 ).  After changing vb.net compiler setting to x86 it works.

tq

[Przemyslaw Czerpak]

Hi,

Alternatively you may use 64bit Harbour version which will generate
64bit compatible OLE server DLLs.

best regards,
Przemek

[Przemyslaw Czerpak]

On Sat, 07 Feb 2015, Tony Quick wrote:

Hi,

> I'm not aware of a way to see who has locks on indexes on a Novell
> network. Do you know of a way?

Sorry I cannot help you. I haven't used Novell netware for many years.
In the past such functionality was avaiable in admin console.

> Also, FWIW, I have had all other users who had the affected index open exit
> their programs, and even with only that one user still having the index
> open, the lock still did not succeed? There's no indication that they have
> lost the connection to the server as other programs that have open are not
> having problems. Is is possible that index corruption could have occurred
> previously, resulting in the apparent endless loop?

It's possible. It's enough that corrupted index has cycle on the path from
root node to leaf node. In such case affected computer should consume 100%
CPU power traversing the index file but it should also block other stations.
Anyhow I would check list of open files on the server on active file range
locks on index files. How depends on your system and here I cannot help you
much untill it's not nix system.

best regards,
Przemek

[elch]

Hi Tony,

extreme stupid suggest .. :-)

Is is possible that index corruption could have occurred previously, resulting in the apparent endless loop?

as earlier mentioned, i'm NOT experienced with IP based NW6 -- is there still this 'load monitor' from former versions (aka NW4.11 SFT) at the server console available ?
There you should be able to see the clipper file locks ( if there were such .. ), and which connections are 'alive' ...

best regards
Rolf

[elch]

ups, Tony

my post looks NOT as it was my intention:
this 'extreme stupid' is related to my own given hint, which you surely already know ..
So i expected to maybe give a stupid suggest -- further i cited the wrong sentence from you ..

excuse
Rolf