xHarbour.org 0.97 - Clipper 5.2 and CDX
Jacek K.
with memos I use if FoxBase standard with index CDX (for read only because CDX in
Clipper 5.2 is not stable).
I have problem, if I re-index in Clipper 5.2 in xHarbour application I have error
(corruption detected)., If I re-index if xHarbour application in Clipper 5.2 I have
error (corruption error).
What I must doing for compatibility CDX in Clipper (5.2e and xHarbour .97)?
--
Jacek K.
--
"Serce rozważne szuka mądrości, usta niemądrych sycą się głupotą."
(Prz 15:14)
"The heart of him that hath understanding seeketh knowledge: but the mouth of fools
feedeth on foolishness."
( Proverbs 15:14)
dlzc
On Sep 25, 1:20 pm, "Jacek K." <jacek.k....@proinfo.xxx.pl> wrote:
> Hi - I have application in Clipper, and i write module
> in xHarbour. Some big tables with memos I use if
> FoxBase standard with index CDX (for read only
> because CDX in Clipper 5.2 is not stable).
>
> I have problem, if I re-index in Clipper 5.2 in
> xHarbour application I have error (corruption
> detected)., If I re-index if xHarbour application in
> Clipper 5.2 I have error (corruption error).
>
> What I must doing for compatibility CDX in Clipper
> (5.2e and xHarbour .97)?
What locking methods are you specifying in the two code bases? Show
us the lines of code on Clipper side (probably where you REQUEST CDX
support) and xHarbour side (where you request CDX support and SET
DBFLOCKSCHEME).
You can check the documentation at xHarbour.com for these...
David A. Smith
Jacek K.
skreślić):
in Clipper:
REQUEST DBFCDX
I'm using DBFCDX from Clipper 5.2 - lib DBFCDX.LIB with ntxpl852.obj
I'm not working on this tables, this tables I redistributing as information to only
reading, but I want prepare indexes for Clipper (some clients)and for xHarbour (new
application)
in xHarbour
REQUEST DBFCDX
request HB_LANG_PL852
request HB_CODEPAGE_PL852
HB_LANGSELECT('PL852')
HB_SETCODEPAGE( "PL852" )
and dbfcdx.lib
If I index in Clipper, in xHarbour is corruption index
If I index in xHarbour, in Clipper is corruption index
in this tables - 135000 rows (records) is memos field, and in dbf-dbt is error in
memo and I must using fox tables.
Jacek K.
DOS Clipper 5.2e + Exospace :
prg:
function TestCDX()
REQUEST DBFCDX
aStrBazy:={{ 'NAZWA', 'C', 20, 0 }}
if ! File( 'TESTCDX.DBF' )
DBCreate( 'TESTCDX', aStrBazy, 'DBFCDX' )
DBUseArea( .t., 'DBFCDX', 'TESTCDX', 'TEST', .f., .f. )
for ii:=32 to 250
TEST->( DBAppend() )
TEST->NAZWA := Chr( ii )+Chr( ii+1 )+'cos tam'
TEST->( DBUnlock() )
next
Select TEST
index on Upper( NAZWA ) tag TESTCDX1 to TESTCDX
TEST->( DBCloseArea() )
elseif ! File('TESTCDX.CDX' )
DBUseArea( .t., 'DBFCDX', 'TESTCDX', 'TEST', .f., .f. )
Select TEST
index on Upper( NAZWA ) tag TESTCDX1 to TESTCDX
TEST->( DBCloseArea() )
endif
DBUseArea( .t., 'DBFCDX', 'TESTCDX', 'TEST', .t., .f. )
set index to TESTCDX
set order to 1
browse(1,1,24,79)
return( nil )
link:
OUTPUT bin\test15.Exe
FILE Obj\test16.Obj
FILE NTXPL852.OBJ
FILE MSGPL852.OBJ
FILE __WAIT_B.OBJ
LIBRARY DBFCDX.LIB
LIBRARY EXOSPACE.LIB
32bit xHarbour 0.97 + BCC 5.1:
prg:
function TestCDX()
REQUEST DBFCDX
REQUEST HB_LANG_PL852
REQUEST HB_CODEPAGE_PL852
HB_LANGSELECT('PL852')
HB_SETCODEPAGE( "PL852" )
SetMode(25,80)
aStrBazy:={{ 'NAZWA', 'C', 20, 0 }}
if ! File( 'TESTCDX.DBF' )
DBCreate( 'TESTCDX', aStrBazy, 'DBFCDX' )
DBUseArea( .t., 'DBFCDX', 'TESTCDX', 'TEST', .f., .f. )
for ii:=32 to 250
TEST->( DBAppend() )
TEST->NAZWA := Chr( ii )+Chr( ii+1 )+'cos tam'
TEST->( DBUnlock() )
next
Select TEST
index on Upper( NAZWA ) tag TESTCDX1 to TESTCDX
TEST->( DBCloseArea() )
elseif ! File('TESTCDX.CDX' )
DBUseArea( .t., 'DBFCDX', 'TESTCDX', 'TEST', .f., .f. )
Select TEST
index on Upper( NAZWA ) tag TESTCDX1 to TESTCDX
TEST->( DBCloseArea() )
endif
DBUseArea( .t., 'DBFCDX', 'TESTCDX', 'TEST', .t., .f. )
set index to TESTCDX
set order to 1
browse(1,1,24,79)
return( nil )
link:
D:\PRG\CLP\APTEKA_M\test_cdx\Obj\test32.Obj +
C:\xHrb\BCC55\Lib\C0W32.OBJ, +
D:\PRG\CLP\APTEKA_M\test_cdx\bin\test32.Exe, +
, +
C:\xHrb\xHARB\Lib\common.lib +
C:\xHrb\xHARB\Lib\codepage.lib +
C:\xHrb\xHARB\Lib\vm.lib +
C:\xHrb\xHARB\Lib\rtl.lib +
C:\xHrb\xHARB\Lib\pcrepos.lib +
C:\xHrb\xHARB\Lib\gtwin.lib +
C:\xHrb\xHARB\Lib\lang.lib +
C:\xHrb\xHARB\Lib\rdd.lib +
C:\xHrb\xHARB\Lib\macro.lib +
C:\xHrb\xHARB\Lib\pp.lib +
C:\xHrb\xHARB\Lib\dbfdbt.lib +
C:\xHrb\xHARB\Lib\dbfntx.lib +
C:\xHrb\xHARB\Lib\dbffpt.lib +
C:\xHrb\xHARB\Lib\dbfcdx.lib +
C:\xHrb\xHARB\Lib\hsx.lib +
C:\xHrb\xHARB\Lib\hbsix.lib +
C:\xHrb\xHARB\Lib\ct.lib +
C:\xHrb\xHARB\Lib\tip.lib +
C:\xHrb\xHARB\Lib\hbzip.lib +
C:\xHrb\BCC55\Lib\CW32.LIB +
C:\xHrb\BCC55\Lib\IMPORT32.LIB +
C:\xHrb\xHARB\Lib\debug.lib
In tis example - TESTCDX.CDX produced in DOS is different than produced in 32bit
xHarbour - why?, CDX will be compatibility and the same. In big tables is error.
Al Acker
index compatibilities. Maybe you should consider a different backend?
Al
"Jacek K." <jacek...@proinfo.xxx.pl> wrote in message
news:gbh3vm$i3r$1...@inews.gazeta.pl...
> -- "Serce rozwazne szuka madrosci, usta niemadrych syca sie glupota."
Jacek K.
(niepotrzebne skreślić):
> It's amazing that after all this time, people here are still working on
> index compatibilities. Maybe you should consider a different backend?
>
> Al
>
I thing - that CDX compatibility with CA-Clipper 5.3 not 5.2 :(
--
Jacek K.
--
"Serce rozważne szuka mądrości, usta niemądrych sycą się głupotą."
N:dlzc D:aol T:com (dlzc)
"Jacek K." <jacek...@proinfo.xxx.pl> wrote in message
news:gbi33d$ahu$1...@inews.gazeta.pl...
> Dnia 2008-09-26 03:22, użytkowniczka/użytkownik Al Acker
> napisała/napisał (niepotrzebne skreślić):
>> It's amazing that after all this time, people here are
>> still working on index compatibilities. Maybe you
>> should consider a different backend?
>
> I thing - that CDX compatibility with CA-Clipper
> 5.3 not 5.2 :(
The "only" thing that causes issues for you is that 5.2's method
of emulating FoxPro locking is different than 5.3's (I guess).
xHarbour can lock compatible with 5.2 native locking, if you'll
check the documentation (at xHarbour.com if nowhere else).
Al was trying to point out that operating an old Clipper code
base is the source of this problem. Upgrading to one of the
flavors of SQL will take care of this.
David A. Smith
dlzc
On Sep 25, 2:19 pm, "Jacek K." <jacek.k....@proinfo.xxx.pl> wrote:
> Dnia 25.09.2008 22:48, użytkowniczka/użytkownikdlzcnapisała/napisał (niepotrzebne
> skreślić):
> > On Sep 25, 1:20 pm, "Jacek K." <jacek.k....@proinfo.xxx.pl> wrote:
> >> Hi - I have application in Clipper, and i write module
> >> in xHarbour. Some big tables with memos I use if
> >> FoxBase standard with index CDX (for read only
> >> because CDX in Clipper 5.2 is not stable).
>
> >> I have problem, if I re-index in Clipper 5.2 in
> >> xHarbour application I have error (corruption
> >> detected)., If I re-index if xHarbour application in
> >> Clipper 5.2 I have error (corruption error).
>
> >> What I must doing for compatibility CDX in Clipper
> >> (5.2e and xHarbour .97)?
>
> > What locking methods are you specifying in the
> > two code bases? Show us the lines of code on
> > Clipper side (probably where you REQUEST CDX
> > support) and xHarbour side (where you request
> > CDX support and SET DBFLOCKSCHEME).
>
> > You can check the documentation at
> > xHarbour.com for these...
>
> in Clipper:
> REQUEST DBFCDX
>
> I'm using DBFCDX from Clipper 5.2 - lib
> DBFCDX.LIB with ntxpl852.obj
I understand there are problems / limitations with combining the CDX
library and overwriting parts of it with this NTX obj file. I hope
Klas can chime in here, if he sees a problem...
> I'm not working on this tables, this tables I
> redistributing as information to only reading,
> but I want prepare indexes for Clipper (some
> clients)and for xHarbour (new application)
>
> in xHarbour
>
> REQUEST DBFCDX
> request HB_LANG_PL852
> request HB_CODEPAGE_PL852
> HB_LANGSELECT('PL852')
> HB_SETCODEPAGE( "PL852" )
> and dbfcdx.lib
And where do you set the lock scheme? That reference above (SET
DBFLOCKSCHEME) was supposed to be a hint.
David A. Smith
Al Acker
Al was trying to point out that operating an old Clipper code
base is the source of this problem. Upgrading to one of the
flavors of SQL will take care of this
>>
Exactly, or even something like Advantage. I think I've been using
Advantage for a lot of my stuff since back in the 90's and it's all
compatible. I can write something in Clipper, Borland C++, VO, and now even
Vulcan and they can all talk to the same backend.
Don't get me wrong, I'm not saying Advantage is the only way, I just use it
as an example.... heck there's a ton of SQLs out there ( some free ) that
you can use.
Al
"N:dlzc D:aol T:com (dlzc)" <dl...@cox.net> wrote in message
news:Kg5Dk.40486$tp1....@newsfe06.iad...
N:dlzc D:aol T:com (dlzc)
"Jacek K." <jacek...@proinfo.xxx.pl> wrote in message
news:gbgv7t$e36$1...@inews.gazeta.pl...
> Dnia 25.09.2008 22:48, uzytkowniczka/uzytkownik dlzc
> napisala/napisal (niepotrzebne skreslic):
>> On Sep 25, 1:20 pm, "Jacek K." <jacek.k....@proinfo.xxx.pl>
>> wrote:
>>> Hi - I have application in Clipper, and i write module
>>> in xHarbour. Some big tables with memos I use if
>>> FoxBase standard with index CDX (for read only
>>> because CDX in Clipper 5.2 is not stable).
>>>
>>> I have problem, if I re-index in Clipper 5.2 in
>>> xHarbour application I have error (corruption
>>> detected)., If I re-index if xHarbour application in
>>> Clipper 5.2 I have error (corruption error).
>>>
>>> What I must doing for compatibility CDX in
>>> Clipper (5.2e and xHarbour .97)?
>>
>> What locking methods are you specifying in
>> the two code bases? Show us the lines of
>> code on Clipper side (probably where you
>> REQUEST CDX support) and xHarbour side
>> (where you request CDX support and SET
>> DBFLOCKSCHEME).
>
> in Clipper:
> REQUEST DBFCDX
>
> I'm using DBFCDX from Clipper 5.2 - lib
> DBFCDX.LIB with ntxpl852.obj
There are a number of web pages that discuss problems with this
.obj file, placing limits on the index key...
This may be perfectly correct, but it seems odd to load a CDX
lib, the overwrite part of it with an NTX obj file... I wish
Klas would weigh in
...
> in xHarbour
>
> REQUEST DBFCDX
> request HB_LANG_PL852
> request HB_CODEPAGE_PL852
> HB_LANGSELECT('PL852')
> HB_SETCODEPAGE( "PL852" )
> and dbfcdx.lib
And where do you set the locking scheme to foxpro? What I said
was supposed to be a HINT! Perhaps I was too subtle... ;>)
David A. Smith
Patrick Mast
Nice to hear form you! ;-)
What are you up to lately?
--
Sincerely,
Patrick Mast,
xHarbour.com
Al Acker
clients wanted to move to net. So I started working with Visual Studio... I
didn't care much for their C++ but I stumbled onto Vulcan and it's a very
nice mix. A Visual Studio language with a Clipper, VO, C# flavor <g>. So
I've been doing some apps in it.... so far I'm very impressed with it.
Visual Studio is a great IDE and Vulcan produces true blue NET apps... nice
combination..
What's new over here? Is Phil still the project manager? Have you gone on
any cool trips lately? I always enjoyed your post cards <g>
Al
"Patrick Mast" <Patrick.Rem...@xHarbour.com> wrote in message
news:2008092709242216807-PatrickRemoveThisMast@xHarbourcom...
Patrick Mast
> Still coding away <g>. Was doing a lot of work in Borland C++ but a lot of
> clients wanted to move to net. So I started working with Visual Studio... I
> didn't care much for their C++ but I stumbled onto Vulcan and it's a very
> nice mix. A Visual Studio language with a Clipper, VO, C# flavor <g>. So
> I've been doing some apps in it.... so far I'm very impressed with it.
> Visual Studio is a great IDE and Vulcan produces true blue NET apps... nice
> combination..
Great!
Why do your clients want .NET? What advantages doe they have with .NET apps?
My clients don't care what I use, as long as it works OK, does not have
any bugs, works fast and looks and feels nice. ;-)
> What's new over here? Is Phil still the project manager?
Yes, he is on the Harbour Project. This is the NG for xHarbour, the
Extended Harbour.
> Have you gone on any cool trips lately? I always enjoyed your post cards <g>
Yes, but the girls are SO nice over there that I'm a bit shy to send
you postcards of them Al.. ;-))))
I'm heading of to Paris in a few weeks. Email me you home address, and
I will try to look away on the "Nice Girls Postcards" and send you one
of the city landscape ;-)))))
Patrick
Al Acker
I'll get you that address today !!!
As far as Net goes... form the client side, they consider it a safety
factor... it's as "MS" as possible and still use an xbase rooted language.
And as a safety net, they like the idea that their is something like
Reflector out there that could move the app to any other Net Language. It's
very easy to "sell" the client on any Net Language because of this. Also
they like the idea that any net language could be used to add functionality
to the application, not to mention all the third party Net add-ons that can
be used. For the larger clients that want the "windows logo" compliance...
the testing process is easier if you have a true blue Net app.
From the programmers viewpoint, I like the Visual Studio IDE and also the
fact that if you really need something special you can find it out there on
the internet. The people on the Vulcan NGs are very helpful and you have
direct access to the dev team....but at 4AM, sometimes you don't want to
wait for answers <g> If you Google almost any programming question... "how
to do whatever", you're most likely going to get the answer in one of the
net languages... VB, C# etc... and if you see the example in those
languages, it's easy to change the source to work in Vulcan.
The Net framework has what.... something between 4 and 5 THOUSAND classes
now? If you can't find something in there to do what you need, something's
wrong <g>. I know I just stated one of the advantages is the Net third
party...but in truth, with the apps I've done so far, I haven't needed any
of them to do what I've needed to do for my apps.
It may be my imagination but my Net apps seem a little faster than my win32
C++ apps... the only thing I can contribute that to is maybe the Net apps
use memory a little better and it takes advantage of the OS a little
better...but that's just a guess. I don't have any hard facts to back that
up. It's a "feel" I guess.... Anyway, it's a pleasant experience. I
haven't had a problem yet that wasn't my fault and most of the time the
compiler found the error at compile time. Can't ask for anything more than
that.
Al
"Patrick Mast" <Patrick.Rem...@xHarbour.com> wrote in message
news:2008092812400216807-PatrickRemoveThisMast@xHarbourcom...
Patrick Mast
Been busy releasing the new xHarbour Builder Release, so, sorry for the
late reply ;-)
Thanks for the .NET info.
I always ask myself... WHY oh WHY is Microsoft themselves not using
.NET?? I mean, what app's do they sell that are made in for .NET?
Patrick
--
Sincerely,
Patrick Mast,
www.xHarbour.com
FP
> I always ask myself... WHY oh WHY is Microsoft themselves not using
> .NET?? I mean, what app's do they sell that are made in for .NET?
Also considering that opensuse Yast (administration program) is written
in mono (.net)
Francesco
Klas Engwall
>> in Clipper:
>> REQUEST DBFCDX
>>
>> I'm using DBFCDX from Clipper 5.2 - lib
>> DBFCDX.LIB with ntxpl852.obj
>
>There are a number of web pages that discuss problems with this
>.obj file, placing limits on the index key...
>
>This may be perfectly correct, but it seems odd to load a CDX
>lib, the overwrite part of it with an NTX obj file... I wish
>Klas would weigh in
OK, here I am, finally. My Usenet access is getting increasingly
unreliable.
The ntx*.obj files are not specifically related to the NTX RDD. They
are used everwhere where a national sort order is required, so we can
forget about the ntx part of the file name.
Jacek, the question here is if the sort order you have in Clipper and
the one in xHarbour are compatible. I would be surprised if they are
not, but if Clipper and xHarbour corrupt each other's indexes maybe
you should test the compatibility. A simple way to do that is to
create a dbf with one char field and fill 255 records with chr(1) ...
chr(255). Then skip through the indexed file and print recno() for
each record to a text file. If the Clipper and xHarbour versions of
the text file are not identical we will have to investigate why.
My experience from Clipper's Swedish ntxswe.obj is that it is crappy,
so I had to create an equally crappy "SVCLIP" codepage in xHarbour for
compatibility and one correct "SV850" codepage for situations where no
Clipper applications will access the files. Maybe ntxpl852.obj is just
as bad?
Regards,
Klas
-------
klas dot engwall at engwall dot com
http://www.engwall.com/clipper/
The LFN Library for Clipper
The LanMan Library for Clipper
The NFPAT1A Timeslice release patch for the Nanforum Toolkit