> 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.
Ok. I realize. No chance to recompile in Cl53, however, as i don't own it.
> 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.
Ok. My mistake. I based my choice on xHarbour manual saying:
"Setting the locking scheme to 1 will lock the database files like
CA-Clipper 5.2 does. To use CA-Clipper 5.3's locking scheme, set
DBFLOCKSCHEME to 2. This will emulate shared locks using exclusive locks.
Visual FoxPro's locking scheme is selected with DBFLOCKSCHEME set to 3."
> 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.
I ever link ntxita.obj, also in DBFNTX build.
> Harbour and CL53 DBFCDX/COMIX do not support none compound IDX indexes
> so I guess you are using CL52 DBFCDX or SIXCDX driver.
Sorry, i was meaning production ".CDX" multitag indexes...
> 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.
The problem is ONLY in Cl52+DBFCDX. With app built with Harbour or
Cl52+DBFNTX all works fine.
The Rlock() returns .t. in all the builded app, BUT ONLY in
Cl52+DBFCDX exits a "Lock required" error at subsequent field replace.
This happens also if the Cl52+DBFCDX is the ONLY program running on
the network...
So, i think that the problem is not deriving from my code... Same code
works fine in all other points of app updating a record.
> 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.
The feel i receive from your message is that i'm going in a puzzled
challenge, so i think i'll have two options:
A) To leave the Cl52+DBFNTX app, working well from twenty year ago, and
to change the driver of Harbour to DBFNTX
B) To take the courage of replace with Harbour+DBFCDX all the install
I don't know the effectiveness of the DBFNTX in Harbour, so i ask you
if also the A) choice is dangerous and the pure Harbour path is the only
affordable.
My great thanks for your support and precious feedback.
Best regards.
Maurizio
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
