[poniedziałek, 14 styczeń 2008], Jacek Potempa napisał(a):
> Hi All,
> One of our customers have just hit a limit of possible number of records
> in a single table. This limit is a 32-bit "signed int" which gives us
> 2,147,483,647 records per table. It's the maximum value HB_IT_LONG can
> hold on 32-bit system.
No. HB_IT_LONG can support 64bit signed integers when compiled on 32 bit
systems without HB_LONG_LONG_OFF macro.
> The installation uses xHarbour+MEDNTX+Mediator server. I have an idea of
> how to extend the possible RECNO range in Mediator server and MEDNTX
> driver but a question remains how to make xHarbour runtime and functions
> like RECNO(), RECCOUNT(), GOTO() e.t.c to properly interpret at least
> "unsigned int" or even better 64-bit integers.
All of the above functions already uses ULONG values (UINT32 in 32bit
systems and UINT64 in 64bit *nixes) There are only three methods which
can cause problems:
SKIP()
SKIPFILTER()
SKIPRAW()
because on 32bit systemes they are using signed 32bit integeres.
We can also change two members of DBORDERCONDINFO structure:
lStep and lNextCount but it's not strictly necessary. Anyhow if we
want to change them then I suggest to use PHB_ITEM pointers instead
of numbers just like in other similar structures.
Few default workarea methods may be updated to to use HB_LONG instead
of LONG: hb_waEval(), hb_waLocate() and hb_waTrans() but it's also not
strictly necessary.
Then we will only have to make minor modifications in function LASTREC()
and replace:
hb_retnl( ulRecCount );
with:
hb_retnint( ulRecCount );
> I've looked through the xHarbour headers but 64-bit integers are used as
> HB_LONG type only on 64-bit platforms. As changing of thousands of
> workstations to 64-bit Windows is not an option, I need a 64-bit HB_LONG
> on 32-bit Windows.
You are wrong. HB_LONG is 64bit signed integer on 32bit platform if you
do not set HB_LONG_LONG_OFF macro yourself - it's disabled by default.
> I see HB_ARCH_64BIT macro in hbdefs.h but it seems to assume that
> sizeof(short int) < sizeof(int) < sizeof(long) so I am not sure if it is
> of any use for BCC32 or VisualC on WIN32.
HB_ARCH_64BIT means that sizeof( void * ) == 8 and the above is only a
hack to detect such situation - not perfect but works with most of current
computers.
> Does anybody has an idea of how to make xHarbour using 64-bit HB_LONGs
> on WIN32?
Yes - it is 64bit integer by default.
> Possibly its the time to consider some xHarbour extentions which would
> allow 64-bit recno as an option.
> Would be gratefull for any suggestions.
As I've wrote above if SKIP() limit is not a problem then you can use
32bit unsigned numbers with few very small modifications - seems that
only LASTREC() will have to be modified and you can use 32bit unsigned
record numbers of course if you code can support them correctly.
If we are taking about full updating for 64bit record range then we
should change also other things like SKIP*() methods replacing LONG
with HB_LONG - such modification in core code can be done in few minutes.
That's all.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
