DTOS in index
Zeljko
index:
DTOS(MYDATE)
When using SEEK DTOS(mDate) on this index, no date is ever found. Is
this a bug in RDDCDX. The same program when running on CLIPPER5 finds
the date with no problem. Even tried to reindex the table, but it
didn't help.
Przemysław Czerpak
Hi,
No it's not a bug in DBFCDX.
Without any doubts it works correctly and the problem has to be in
your code.
best regards,
Przemek
Gmail
I use Harbour for a while and never had such problem.
Are you sure in did reindex? (delete the index file and reindex it from your
Harbour program)
Do you want to show your code so others can give input to what is wrong with
it?
Qatan
> --
> 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
Zeljko
reading your posts, I decided to reindex from a harbour exe. This
solved the problem. Now it works without problems. Thanks.
Gmail
Although it is possible to share the same index file between Harbour and
Clipper I always recommend to completely forget Clipper index and start over
with Harbour's for safe use and less headaches.
Zeljko
clipper apps to harbour, because I think it's a great tool. The DTOS
index now works fine. But now I have a problem of another kind. I have
Clipper apps and harbour apps writing to the same data (as I'm not
able to convert them all at the same time - it will take some time).
What now happens is that the harbour app just quits when accessing
some data (no error whatsoever - hell to debug). Again, I recompiled
the same code with Clipper and it works. My question is: Is there any
inconsistency (locking, writing) with harbour and clipper apps working
on the same data which I am not aware of?
Gmail
the answer.
In any case what I know is that there are different lock schemes so you will
have to change yours to the same Clipper version you are using.
Please, search the changelog for these (extracted from xHarbour docs):
DBINFO()
DBINFO.CH
RddInfo()
Constant Value Description
DB_DBFLOCK_DEFAULT 0 Default locking scheme
DB_DBFLOCK_CLIP 1 Clipper 5.2 locking scheme
DB_DBFLOCK_CL53 2 Clipper 5.3 locking scheme
DB_DBFLOCK_VFP 3 Visual FoxPro locking scheme
DB_DBFLOCK_CL53EXT 4 Emulated shared locking
DB_DBFLOCK_XHB64 5 Locking scheme for files > 4GB
Zeljko
currently using Clipper 5.3 apps concurrently with harbour (both write
data). This would then require a call to DB_DBFLOCK_CL53. But I'm also
using a .NET app that uses the data for reading purposes only through
VFP OLEDB (guess it would be DB_DBFLOCK_VFP THEN). Currently I have
not set any record locking scheme (is DB_DBFLOCK_CL53 the default?).
Teo Fonrouge
On Nov 23, 2011, at 9:36 AM, Zeljko wrote:
> OK. To explain my situation. I'm in the process of converting all
> clipper apps to harbour, because I think it's a great tool. The DTOS
> index now works fine. But now I have a problem of another kind. I have
> Clipper apps and harbour apps writing to the same data (as I'm not
> able to convert them all at the same time - it will take some time).
> What now happens is that the harbour app just quits when accessing
> some data (no error whatsoever - hell to debug). Again, I recompiled
> the same code with Clipper and it works. My question is: Is there any
> inconsistency (locking, writing) with harbour and clipper apps working
> on the same data which I am not aware of?
This has been discused in the past, please check the following google search:
>
>
> On 23 stu, 14:12, "Gmail" <wanstad...@gmail.com> wrote:
>> I am glad it worked.
>>
>> Although it is possible to share the same index file between Harbour and
>> Clipper I always recommend to completely forget Clipper index and start over
>> with Harbour's for safe use and less headaches.
[snip]
HTH,
best regards,
Teo
Gmail
schema is not 53 but Harbour's own (that I belive is somehow better).
Sorry, I do not know much about it but I am sure it was well dicussed and
explained in the past.
Regards,
Gmail
Qatan
Zeljko
SET(_SET_DBFLOCKSCHEME, DB_DBFLOCK_DEFAULT)
? DbInfo(DBI_LOCKSCHEME)
SET DBFLOCKSCHEME TO DB_DBFLOCK_CL53
? DbInfo(DBI_LOCKSCHEME)
SET DBFLOCKSCHEME TO DB_DBFLOCK_VFP
@ 2, 0 say DbInfo(DBI_LOCKSCHEME)
On 23 stu, 19:23, "Gmail" <wanstad...@gmail.com> wrote:
> That's it. It was well explained in the past...
>
> Qatan
>
>
>
>
>
>
>
> ----- Original Message -----
> From: "Teo Fonrouge" <tfonro...@gmail.com>
> To: <harbou...@googlegroups.com>
> Sent: Wednesday, November 23, 2011 14:18
> Subject: Re: [harbour-users] DTOS in index
>
> > Hello Zeljko,
>
> > On Nov 23, 2011, at 9:36 AM, Zeljko wrote:
>
> >> OK. To explain my situation. I'm in the process of converting all
> >> clipper apps to harbour, because I think it's a great tool. The DTOS
> >> index now works fine. But now I have a problem of another kind. I have
> >> Clipper apps and harbour apps writing to the same data (as I'm not
> >> able to convert them all at the same time - it will take some time).
> >> What now happens is that the harbour app just quits when accessing
> >> some data (no error whatsoever - hell to debug). Again, I recompiled
> >> the same code with Clipper and it works. My question is: Is there any
> >> inconsistency (locking, writing) with harbour and clipper apps working
> >> on the same data which I am not aware of?
>
> > This has been discused in the past, please check the following google
> > search:
>
> >http://www.google.com/search?gcx=c&ix=c1&sourceid=chrome&ie=UTF-8&q=h...
Zeljko
What I wanted to say is that:
SET(_SET_DBFLOCKSCHEME, DB_DBFLOCK_DEFAULT)
? DbInfo(DBI_LOCKSCHEME)
SET DBFLOCKSCHEME TO DB_DBFLOCK_CL53
? DbInfo(DBI_LOCKSCHEME)
SET DBFLOCKSCHEME TO DB_DBFLOCK_VFP
? DbInfo(DBI_LOCKSCHEME)
all have 3 as result. This is inconsistent with your excerpt from
Harbour docs.
Zeljko
http://www.mail-archive.com/har...@harbour-project.org/msg24809.html
Tried to contact him by e-mail but got no response so far.
Gmail
The xHarbour docs I cited are just a reference. I doesn't mean that Harbour
works exactly the same way. The best is to check the Teo's message and study
what was explained by Przemek in the past.
Other option that can help you to find out is by checking the CHANGELOG
file. Sometimes it helps a lot.
According to Przemek's message, it is possible to mix DOS Clipper and
Windows (Harbour CDX):
> B) To take the courage of replace with Harbour+DBFCDX all the install
It's probably safer method. Anyhow as long as some network transport
layer does not cause some separate buffering which can cause problems
when DOS and Windows applications access files concurrently then it
should be safe to share database files and indexes between Clipper
and Harbour. It's enough to set compatible national sorting and locking
schemes.
Please check this link:
http://www.matrixlist.com/pipermail/harbour/2010-January/031221.html
I hope it will help you
Qatan
----- Original Message -----
From: "Zeljko" <zeljk...@gmail.com>
To: "Harbour Users" <harbou...@googlegroups.com>
Sent: Wednesday, November 23, 2011 16:32
Subject: [harbour-users] Re: DTOS in index
Przemysław Czerpak
Hi,
> Sorry, Gmail I just hit ENTER
> What I wanted to say is that:
> SET(_SET_DBFLOCKSCHEME, DB_DBFLOCK_DEFAULT)
> ? DbInfo(DBI_LOCKSCHEME)
> SET DBFLOCKSCHEME TO DB_DBFLOCK_CL53
> ? DbInfo(DBI_LOCKSCHEME)
> SET DBFLOCKSCHEME TO DB_DBFLOCK_VFP
> ? DbInfo(DBI_LOCKSCHEME)
> all have 3 as result.
This is not self contain example so I cannot say what exactly
you are doing wrong.
SET DBFLOCKSCHEME TO ...
sets locking scheme for newly open files. It does not change
locking scheme in active workareas.
> This is inconsistent with your excerpt from Harbour docs.
Without any doubts such results are expected in some cases and
I do not know any documentation that suggests sth different.
best regards,
Przemek
Zeljko
said, I'm using it concurrently with a Clipper 5.3 application. In
Clipper I'm linking it with the DBFCDX.RDD (DBFCDX.LIB) and I'm not
setting any locking schema. What do I have to do in Harbour to make it
coexist with the Clipper app. Do I have to call
SET(_SET_DBFLOCKSCHEME, DB_DBFLOCK_CL53)? In Clipper I'm using no
international codepages. In Harbour I have my codepage set to HR852
but using HB_SETTERMCP("HR852","HR646") to get screen conversion to
HR646 (which should be compatible with the standard 437 CP). Am I
doing something terribly wrong?
Przemysław Czerpak
Hi,
> Thank Przemek. Can you help me to set the correct locking scheme. As I
> said, I'm using it concurrently with a Clipper 5.3 application. In
> Clipper I'm linking it with the DBFCDX.RDD (DBFCDX.LIB) and I'm not
> setting any locking schema. What do I have to do in Harbour to make it
> coexist with the Clipper app. Do I have to call
> SET(_SET_DBFLOCKSCHEME, DB_DBFLOCK_CL53)?
DBFCDX from CL52 is SIX3 CDX driver which uses FP (DB_DBFLOCK_VFP)
locking scheme. This is default in Harbour DBFCDX driver so you
do not have to change anything. Please only remember that this
locking scheme uses different RLOCK offsets for tables with and
without production index file (production index is index with the
same name as table). This is standard FP behavior replicated in
Clipper and Harbour.
CDX format allows to create 4 different types of indexes:
1. single tag noncompressed indexes (def.ext: .idx)
2. single tag compressed indexes (def.ext: .idx)
3. multi tag non-compressed indexes (def.ext: .cdx)
4. multi tag compressed indexes (def.ext: .cdx)
Harbour and CL53 DBFCDX (COMIX) support only 4-th format.
CL52 DBFCDX (SIX3) supports 2-nd and 4-th formats. Maybe also 1-st
but I haven't tested it.
I haven't seen CDX driver implementation which supports 3-rd format.
So you cannot share with Clipper single tag .idx files. Just simply
Harbour refuse to open them.
> In Clipper I'm using no
> international codepages. In Harbour I have my codepage set to HR852
> but using HB_SETTERMCP("HR852","HR646") to get screen conversion to
> HR646 (which should be compatible with the standard 437 CP). Am I
> doing something terribly wrong?
No but you should verify if your Clipper version uses binary sorting
by default. The easiest way is compiling and linking test/cpinfo.prg
in the same way as your Clipper application (with the same .obj files
from Clipper distribution). When you execute final executable file you
should see on the screen:
simple byte sorting !!!
If above is true then you should use also in Harbour as main HVM CP (or
at least as table CP set by CODEPAGE clause in USE command) the "EN" CP.
This is default so you should not change it by
SET( _SET_CODEPAGE, ... )
or
hb_cdpSelect( ... )
in your Harbour code.
best regards,
Przemek
Zeljko
reporting simple byte sorting. Does this mean I have to call
hb_cdpSelect("EN"). I thought I was using "HR852" codepage in my
Harbour app (I didn't set the cp at all). After testing it with
cpinfo.prg, I saw I was using the "EN" codepage. But I ws using
HB_SETTERMCP("HR852","HR646") for screen character conversion. Can
this be the reason for the index corruption. Got this in hb_out.log:
Application Internal Error - C:\PRG\DOS\PK8\pk.exe
Terminated at: 2011.11.23 14:31:35
Unrecoverable error 9201: hb_cdxPageKeyLeafBalance: index corrupted.
Called from DBCOMMIT(0)
Called from XYKLJUC(1667) in XYLIB.prg
Called from ITEMRGST09(209) in REZIDENT.prg
Called from OBRSTC09(2215) in FUNKCIJE.prg
Called from OBRSTC(6) in FUNKCIJE.prg
Called from XYMENU(2825) in XYLIB.prg
Called from XYMENU(2814) in XYLIB.prg
Called from XYMENU(2814) in XYLIB.prg
Called from PK(301) in PK.prg
Przemysław Czerpak
Hi,
> I tested my Clipper app with cpinfo.prg as you suggested. It is
> reporting simple byte sorting. Does this mean I have to call
> hb_cdpSelect("EN"). I thought I was using "HR852" codepage in my
> Harbour app (I didn't set the cp at all). After testing it with
> cpinfo.prg, I saw I was using the "EN" codepage. But I ws using
> HB_SETTERMCP("HR852","HR646") for screen character conversion. Can
> this be the reason for the index corruption.
No, this should not cause problems.
> Got this in hb_out.log:
> Application Internal Error - C:\PRG\DOS\PK8\pk.exe
> Terminated at: 2011.11.23 14:31:35
> Unrecoverable error 9201: hb_cdxPageKeyLeafBalance: index corrupted.
It means that your Clipper application corrupted index file.
I do not tolerate any bugs and in Harbour DBFCDX code I implemented
many different procedures which online verify some index structures
to check if they are valid so this code quit fast detects any problems
reporting them like above.
Clipper does not has such code so it usually process corrupted indexes
without errors just simply accessing wrong data.
Corruption problems are expected when you are using DBFCDX from CL5.2
There are many documented bugs in this RDD and it was never production
ready.
I was also user of commercial SIX3 library and I had to switch
from SIXCDX to SIXNSX due to serious bugs and index corruption
in my Clipper application - most of them were classic buffer
overflow which caused index corruption sometime with application
crash even in code working standalone with tables open in
exclusive mode.
Some people like Mindaugas tried to dig SIX3 problems more deeply
disassembling some part of SIX3 code and creating patches for few
bugs they exploited (AFAIK they are available in the inet).
Anyhow they do not fix all known problems so you will have to leave
with them until you will not stop to use this RDD.
In Harbour I also created SIXCDX RDD which is slightly modified DBFCDX
code. It tries to replicate some SIXCDX (CL52 DBFCDX) specific behaviors
which are different then COMIX (CL53 DBFCDX). Additionally in this RDD
I reduced maximum compression level in leaf nodes disabling compressing
of trailing spaces by key prefix. Such indexes are compressed in less
efficient way but they also exploit less bugs in SIX3/CL52 CDX RDDs.
you can use
REQUEST SIXCDX
rddSetDefault( "SIXCDX" )
in your Harbour application to reduce corruption problems when you share
data with SIX3/CL52 CDX RDDs but for sure it's not perfect solution due
to bugs in these Clipper's RDDs.
best regards,
Przemek
Zeljko
app doesn't care if the index is corrupted. Harbour seems to care. I
decided to shut down the Clipper app for one day and go exclusively
with Harbour. I reindexed all indexes usin CP HR646 (the table data is
in EN). Then I set the default CP in my App to HR646 and made the
screen conversion work with HB_SETTERMCP("HR852","HR646"). All seemed
to work quite well. No index corruption all day (data files are over 1
GB). But I had another great problem that made me reverse to
Clipper( temporarily I hope). All index seeks with Croatian diacritic
characters don't work if the last character in the index ends with a
diacritic Croatian character. I.e. if I seek "DEŽ" OR SET filter to
"DEŽ", I get all table rows beginning with "DE". The funny thing is
that "OČN" seek works. The DBF data was written correctly (HR646/EN).
I thought that HR646 and EN code pages were interchangeable, but it
seems not. Have to investigate this a bit more. I even tried to set
HB_SETTERMCP("HR852","HR646") for screen conversion, but this doesn't
work.
Massimo Belgrano
aDbf := {}
AADD( aDbf, { "name", "C", 40, 0 } )
dbCreate("dbtest",aDbf)
USE dbtest EXCLUSIVE
index on fc to DBtest_i1
use dbtest SHARED
? "INSERT (NO MEMO): "
st = seconds()
append blank
replace NAME with " DEŽ ER"
append blank
replace NAME with " DAŽ ER"
commit
SEEK DAŽ
DBEDIT()
2011/11/24 Zeljko <zeljk...@gmail.com>
>
> Hi Przemek, what you say is certainly true. It seems that the Clipper
> app doesn't care if the index is corrupted. Harbour seems to care. I
> decided to shut down the Clipper app for one day and go exclusively
> with Harbour. I reindexed all indexes usin CP HR646 (the table data is
> in EN). Then I set the default CP in my App to HR646 and made the
> screen conversion work with HB_SETTERMCP("HR852","HR646"). All seemed
> to work quite well. No index corruption all day (data files are over 1
> GB). But I had another great problem that made me reverse to
> Clipper( temporarily I hope). All index seeks with Croatian diacritic
> characters don't work if the last character in the index ends with a
> diacritic Croatian character. I.e. if I seek "DEŽ" OR SET filter to
> "DEŽ", I get all table rows beginning with "DE". The funny thing is
> that "OČN" seek works. The DBF data was written correctly (HR646/EN).
> I thought that HR646 and EN code pages were interchangeable, but it
> seems not. Have to investigate this a bit more. I even tried to set
> HB_SETTERMCP("HR852","HR646") for screen conversion, but this doesn't
> work.
>
Massimo Belgrano
ì
Zeljko
Haven't got the strength to do it today, but I'll do it first thing
tomorrow. I already had a peek into the source code after the
unsuccessfull launch of the app(not all of the code is mine) and I'm
not anymore sure it is a harbour problem. The code makes besides
dbseek some other calculations on the search string (gets the last
character of the string to search and ads a ASCII value incremented by
one. Something like this:
seekL = SUBS(FC_LAST,1,yLen-1) + CHR(ASC(SUBS(FC_LAST,yLen,1)))
This works fine in Clipper with CP 437 (EN). I'm quite sure now that
cp HR646 and cp EN are not the same (though they use the same limited
ASCII set of characters). After returning to the Clipper app, I had to
reindex the data with CP EN (437) to make it work.
On 24 stu, 17:24, Massimo Belgrano <mbelgr...@deltain.it> wrote:
> Can you post a reduced sample
> aDbf := {}
> AADD( aDbf, { "name", "C", 40, 0 } )
> dbCreate("dbtest",aDbf)
> USE dbtest EXCLUSIVE
> index on fc to DBtest_i1
> use dbtest SHARED
>
> ? "INSERT (NO MEMO): "
> st = seconds()
> append blank
> replace NAME with " DEŽ ER"
> append blank
> replace NAME with " DAŽ ER"
> commit
> SEEK DAŽ
> DBEDIT()
> 2011/11/24 Zeljko <zeljko.s...@gmail.com>
Massimo Belgrano
Hi Massimo. I lost ten hours of nerves today with unsatisfied users.
Haven't got the strength to do it today, but I'll do it first thing
tomorrow. I already had a peek into the source code after the
unsuccessfull launch of the app(not all of the code is mine) and I'm
not anymore sure it is a harbour problem. The code makes besides
dbseek some other calculations on the search string (gets the last
character of the string to search and ads a ASCII value incremented by
one. Something like this:
seekL = SUBS(FC_LAST,1,yLen-1) + CHR(ASC(SUBS(FC_LAST,yLen,1)))
This works fine in Clipper with CP 437 (EN). I'm quite sure now that
cp HR646 and cp EN are not the same (though they use the same limited
ASCII set of characters). After returning to the Clipper app, I had to
reindex the data with CP EN (437) to make it work.
Massimo Belgrano
Vito
I was using Clipper 5.2 with CRONTX ("CROSCII"). Somewhere in 2009 I
started with Harbour. With Przemek's help regarding CP questions all
my Clipper apps were "converted" to Harbour in less then two weeks
(most of this was developing aditional WIN printing capabilities for
my apps, based on Win_Prn())
Right now, my source/dbf configuration is:
1. My sources (string constants in prg's ) are writen in HR646
("CROSCII")
2. Data in my DBF Tables are in HR646, Indexes are NTX
3. I'm using gtWVT (or rarely gtWIN)
Settings in my Harbour APPS:
// ### Begin code
REQUEST HB_CODEPAGE_HR646
REQUEST HB_CODEPAGE_HR852
REQUEST HB_CODEPAGE_HRWIN
REQUEST HB_CODEPAGE_HRISO
REQUEST HB_LANG_HR646
REQUEST HB_LANG_HR852
REQUEST HB_LANG_HRWIN
REQUEST HB_LANG_HRISO
/*******************************
* Function: VjcHarbour()
* Notes :
*/
INIT PROCEDURE VjcHarbour
LOCAL cGtName
LOCAL nWidth, nHeight, nFontH, nFontW
cGtName := HB_GtVersion(0)
If cGtName == 'NUL' // No GT
QUIT
ElseIF cGtName == 'WIN'
// hb201 - //GTWIN
HB_CdpSelect("HR646") // Default CP
HB_SetTermCP('HRWIN', 'HR646', .T.) // Keyboard, Display
HB_GtInfo(HB_GTI_FONTNAME, 'Lucida Console') // Font
ElseIF cGtName == 'WVT'
HB_CdpSelect("HR646")
HB_SetTermCP('HRWIN', 'HR646', .T.)
HB_GtInfo(HB_GTI_FONTNAME, 'Lucida Console')
HB_GtInfo(HB_GTI_ICONFILE, 'MCF003_32.ico')
// Maximal, not FullScreen window
nWidth := HB_GtInfo(HB_GTI_DESKTOPWIDTH)
nHeight := HB_GtInfo(HB_GTI_DESKTOPHEIGHT)
nFontH := Int(nHeight/25)
nFontW := Int(nWidth /80)
HB_GtInfo(HB_GTI_FONTWIDTH, nFontW)
HB_GtInfo(HB_GTI_FONTSIZE , nFontH)
EndIF
set(_SET_EVENTMASK, INKEY_ALL) // All events (mouse too)
MSetCursor(.T.)
SetMode(25, 80)
SetBlink(.F.)
HB_GtInfo(HB_GTI_CLOSABLE, .F.)
RETURN
//*** End of VJCHARBOUR ***********
// ### End code
With this settings all Keyboard/Display/DBF/WinPrinter CP conversions
are done automaticaly.
In case that you need access to data writen with different CP, it's
simply question of defining CP when opening Database.
For example (Data stored in MS SQL Server, Code Page
'Croatian_CI_AS'):
// ### Begin code
#Include "hbrddsql.ch"
REQUEST SQLMIX, SDDODBC
Procedure Main
Local cDsn, nConn
// ....
// cDsn := Your ODBC connection string
nConn := RddInfo(RDDI_CONNECT, {'ODBC', cDSN}, 'SQLMIX')
DbUseArea(.T., 'SQLMIX', 'Select * From ViewVPlaner', .T., .F.,
'HRWIN', nConn)
// ....
Return
// ### End code
Perhaps this could help you.
Best Regards,
Vito
> > ì- Sakrij citirani tekst -
>
> - Prikaži citirani tekst -
Zeljko
totally. I am investigating this thing right now and I'll report back
as soon as I have more info. Most of the problems I encounterd so far
were not with harbour but with Clipper inonsistencies (Clipper doesn't
behave as expected).
Zeljko
nearly the same configuration as you (and Przemek helped me a lot with
this). The only difference is this:
HB_SetTermCP('HRWIN', 'HR646', .T.)
parameter mean?
Vito
Glad to see someone from Croatia :)
Syntax is (see in ChangeLog):
HB_SetKeyCP( <cTermCP> [,<cHostCP>] )
HB_SetDispCP( <cTermCP> [,<cHostCP>] [,<lBoxChar>])
HB_SetTermCP( <cTermCP> [,<cHostCP>] [,<lBoxChar>])
<cTermCP>
is encoding used on external (terminal) side
<cHostCP>
is encoding used internally, if not given then current code page set
HB_SETCODEPAGE() is used. Some of GTs which uses unicode output may
ignore <cTermCP>
<lBoxChar>
is optional parameter which interacts with dispbox() output
disabling switching to alternate character set in some GTs. It
effectively causes that if internal (host) code page contains some
letters on the box char positions then they will be shown also by box
drawing functions like dispbox() instead of CP437 characters. In some
cases it could be useful. By default lBoxChar is not set and GTs which
can switch between standard and alternate character set (GTCRS, GTSLN)
will try to use alternate character set for box drawing functions.
Best regards,
Vito
Zeljko
hb30\doc (i.e. harbour.hbd). Some posts said I should your hbide to
open it, but had no success.
Zeljko
to the fact that clipper is doing binary sort by default and harbour
is not). I guess this is a question for Przemek. The problem in the
code I maintain is that it is setting boundaries for the first and
last record to browse. It looks for the browse string filter, i.e.
"DE@" ( @ is ASCII 64), seeks the first record, set the browse start
boundary to this record, gets the last character of the search string
and replaces it with the CHR(ASC("@")+1). In cp HR646 this is the "A"
character (ASCII 65). It then seeks for this string and sets the end
boundary to this record. When showing the record to browse it starts
with the start boundary record and lists them till it gets to the end
browse boundary record. This worked fine in Clipper with CP437. In
Harbour with CP646 it does not. It would solve my problem if I had a
means to get the next character in the sort order (i.e. what is the
next sort character after "@")
Vito
HbIde is the answer.
My config:
Harbour (3.0.0) is instaled in C:\Hb300
In HbIde:
Setup - HbIde Setup - Paths:
Harbour Root := C:/Hb300
After that (select from menu):
View - Harbour Documentation
Regards,
Vito
On 25 stu, 08:47, Zeljko <zeljko.s...@gmail.com> wrote:
> > > parameter mean?- Sakrij citirani tekst -
Massimo Belgrano
http://harbourlanguage.blogspot.com/2011/01/how-to-create-harbour-documentation.html
I invite to collaborate anyone who is interested in harbour language and is able to make a contribution. We are looking for developer,documentation writer, sponsors, sympathizers and friends. Any kind of collaboration is welcome. Possibly you may have some suggestions, we will be glad to hear from you.
2011/11/25 Vito <vitomir.c...@mcfrontis.hr>
> 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
Massimo Belgrano
Zeljko
Actually it did work but you have to close hbide and start the program
again. If you just change the path without reopening hbide, the
documentation doesn't show. It will be much easier now with the
documentation at hand.
> > - Prika¾i citirani tekst -
Zeljko
awesome. I have quite a lot of experience in Clipper, C#, Asp.Net,
ADO. I also have some experience in programing C++ (even C but that's
some 10 years past of experience). If the Harbour crew needs help, let
me know how I can participate.
Massimo Belgrano
and post message regarding you are glad to participate, request how you can participate.
--
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
Massimo Belgrano
Zeljko
program:
Function main()
REQUEST HB_CODEPAGE_HR852
REQUEST HB_CODEPAGE_HR646
setmode(25,80)
HB_CDPSELECT("HR646")
HB_SETTERMCP( "HR852","HR646" )
SET EXCLUSIVE ON
use TEST
INDEX ON STRING TO TEST1
ZAP
For I = 1 to 256
append blank
replace code with i,;
string with chr(i)
next
BROWSE()
return
This way I got the ASCII sort sequence used when not implementing
binary sort. I saw i.e. than the character "@" (ASCII 64) is followed
by character "_" (ASCII 95) in CP HR646 sort mode (and not by ASCII 96
character). The rest was easy to implement. Does anybody know if there
is a hash table with all the codes accessible through Harbour for a
particular code page? I implemented my own, but I'm sure there is a
better way to do this.
On 25 stu, 13:34, Massimo Belgrano <mbelgr...@deltain.it> wrote:
> Join on developer list herehttps://groups.google.com/forum/#!forum/harbour-devel
>
> and post message regarding you are glad to participate, request how you
> can participate.
>
> 2011/11/25 Zeljko <zeljko.s...@gmail.com>
Zeljko
I saw i.e. than the character "@" (ASCII 64) is followed
by character "_" (ASCII 95) in CP HR646 sort mode (and not by ASCII
96
character).
should read
I saw i.e. than the character "@" (ASCII 64) is followed
by character "_" (ASCII 95) in CP HR646 sort mode (and not by ASCII
65
character).
Przemysław Czerpak
Hi,
> Finally got it to work. If anybody is interested, I wrote a small test
> program:
> Function main()
> REQUEST HB_CODEPAGE_HR852
> REQUEST HB_CODEPAGE_HR646
> setmode(25,80)
> HB_CDPSELECT("HR646")
This line changes internal sort order.
HVM CP set by HB_CDPSELECT( <cCP> ) or SET( _SET_CODEPAGE, <cCP> ) is
used also by RDD to set index collation order. If you had such function
also in you application which tried to shared data with Clipper then
both used different collation orders and indexes were not compatible.
If you want to use binary sorting then you cannot set HVM CP tp HR646.
> HB_SETTERMCP( "HR852","HR646" )
> SET EXCLUSIVE ON
> use TEST
> INDEX ON STRING TO TEST1
> ZAP
> For I = 1 to 256
> append blank
> replace code with i,;
> string with chr(i)
> next
> BROWSE()
> return
>
> This way I got the ASCII sort sequence used when not implementing
> binary sort. I saw i.e. than the character "@" (ASCII 64) is followed
> by character "_" (ASCII 95) in CP HR646 sort mode (and not by ASCII 96
> character). The rest was easy to implement. Does anybody know if there
> is a hash table with all the codes accessible through Harbour for a
> particular code page? I implemented my own, but I'm sure there is a
> better way to do this.
The exact collation order for HR646 is defined in
/src/codepage/cphr646.c:
#define HB_CP_UPPER "ABC^]D\\EFGHIJKLMNOPQRS[TUVWXYZ@"
#define HB_CP_LOWER "abc~}d|efghijklmnopqrs{tuvwxyz`"
best regards,
Przemek
Zeljko
Guess this caused it.