On Mon, 25 Jan 2010, Maurizio la Cecilia wrote:
Hi,
> Sorry for reopening a very old and OT thread, but my needs are quite the same
> as Viktor's one and i think something changed after 2005.
> I ported successfully a large clipper 5.2e application, working on many
> networks, to Harbour 2.0.
> Now, before to swap the installation to Harbour version, i would to test the
> effectiveness of the job using one or few Harbour workstation concurrently
> with old Clipper ones on the same network.
> Thus, i changed the Clipper app to use the DBFCDX driver and compiled
> Harbour using the same driver and setting the locking scheme to CLIP (not
> CLIP53). The adopted code is:
CL52 DBFCDX/SIX3 SIXCDX drivers are broken and can corrupt index files.
so I cannot give you any guaranties that it will work. Anyhow if
you want to use it and access the same index files by Harbour then
you should use in Harbour SIXCDX RDD which tries to replicate some
low level SIXCDX behavior. It creates less efficient indexes in some
cases but it's a workaround for some CL52/SIXCDX bugs.
CL53 DBFCDX/COMIX seems to be much better choice for Clipper.
Additionally you have to chose _EXACTLY_ the same locking schemes in
both compilers.
CL52 DBFCDX/SIXCDX uses FP locking. CL53 DBFCDX/COMIX use CL53 locking
but it can be changed to FP locking if you link with your application
cdxlock.obj
> REQUEST DBFCDX
> RDDSetDefault("DBFCDX")
> RddInfo( RDDI_LOCKSCHEME, DB_DBFLOCK_CLIP )
None of Clipper CDX drivers uses such locking scheme so it's wrong.
> REQUEST HB_LANG_IT
> REQUEST HB_CODEPAGE_IT850
> hb_cdpSelect('IT850')
> hb_LangSelect('IT')
If you are using HB_CODEPAGE_IT850 in Harbour then you have to link your
Clipper application with ntxita.obj. Otherwise index files will be corrupted
because Clipper and Harbour will use different collation orders.
> Apart of a dirty Clipper problem about the compound indexes (i posted
> yesterday a message on the google clipper group) solved using the INDEX
> command in place of the OrdCondSet()/OrdCreate() pair, the program crashes
Harbour and CL53 DBFCDX/COMIX do not support none compound IDX indexes
so I guess you are using CL52 DBFCDX or SIXCDX driver.
> only in one function, giving a "lock required" error after a successfully
> lock of the same record. The strange thing is that the flow is apparently
> the same of other parts of the application working fine.
In Clipper and Harbour 1022 "Lock required" RT error is logical error.
It means that programmer didn't successfully locked the record. The
physical record lock is not checked when this error is generated.
It means that it's a problem with application code. Check why it's
exploited when you compile it using Harbour. It's possible that setting
valid locks scheme will hide the problem but for sure it will not fix
the code. Such error should not appear in code which always checks
results of RLOCK/FLOCK operations and never tries to write to not locked
record so it's something what you should try to locate and fix in your code.
> Thus, i'm thinking that i gone wrong in some configuration option or i'm
> ignoring some bug of the adopted implementation.
> Ther'is any hint about the DBFCDX driver coexistence? Ther'is another better
> path to try (not SQL based, as i need to mantain DBF approach before
> quitting old Clipper world).
See above. You have to use exactly the same locking scheme and national
sorting order inb both applications. If you are using CL52 DBFCDX or SIXCDX
then use in Harbour SIXCDX too. If you are using CL53 DBFCDX or COMIX them
use in Harbour DBFCDX.
CL52 DBFCDX and SIXCDX have serious bugs and for me should never be used
in production environment. Anyhow it's possible that your code does not
exploit them very often so you can live with it.
HTH,
best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
