PC Toledo

Nada tem a ver com hbsix, e sim sixcdx.lib.

* Harbour Project source code:
* SIX compatible functions:
* sxChar()
* sxNum()
* sxDate()
* sxLog()
* Sx_Compress()
* Sx_Decompress()
* Sx_TagInfo()
* Sx_TagCount()
* Sx_Tags()
* Sx_SetTag()
* Sx_KillTag()
* Sx_FileOrder()
* Sx_SetFileOrd()
* RDD_Count()
* RDD_Name()
* RDD_Info()
* Sx_IsDBT()
* Sx_AutoOpen()
* Sx_AutoShare()
* Sx_BLOB2File()
* Sx_File2BLOB()
* Sx_dbCreate()
* Sx_VSigLen()
* Sx_MemoExt()
* Sx_MemoBlk()
* Sx_SetMemoBlock()
* Sx_StrxCheck()
* Sx_LockRetry()
* Sx_IsLocked()
* Sx_SetTrigger()
* Sx_VFGet()

* Harbour Project source code:
* SIX compatible functions:
* Sx_DefTrigger()

* Harbour Project source code:
* SIX compatible functions:
* _sx_INIinit()
* Sx_INIheader()
*

No Harbour é hbsix, no xHarbour é sixcdx que é o nome antigo ainda.

Przemek Q: SIX "FOR" clause Clipper/Harbour difference

The senior Clipper programmer here wanted me to ask someone this question. I couldn't think of a better person to ask than you!

Question:
-------------

When a table's index file is re-opened (it was previously created), does it have to evaluate the FOR clause, or can it wait to do that only when a value in the table row changes?

In SIX, it does not check the FOR expression when it opens an index file. In Harbour, when you open the index file it will evaluate the FOR expression, and if any variables or functions in that expression are not visible, the system will crash (undefined variable/function).

eg. Index on iif(x=3,"a","b") tag "temp" of test.cdx
When the index is opened (set index to...) if X is not visible, Harbour will crash. In Clipper, it will only crash if a row in the table changes value and the index needs to be updated.

Unfortunately, my code has lots of specialized temporary indexes that are created and then used within a specific function. This does not present a problem until a timer event fires, which needs to close files to do "something". Upon reopening those file before RETURNing back the original function, the system crashes because the FOR in the index has variables out of scope.

I can rewrite these but I will probably have to use Private variables and non-Static functions.

Many thanks in advance

--
smu johnson <smujohnson@gmail.com>

On Tue, 02 Feb 2010, smu johnson wrote:

Hi,

> > When a table's index file is re-opened (it was previously created), does it
> > have to evaluate the FOR clause, or can it wait to do that only when a value
> > in the table row changes?
It does not need to be evaluated and can wait but it has to be valid
expression which can be compiled by macrocompiler.
Anyhow few times people asked to make such test evaluation to detect
some potential problems like missing functions, incompatible aliases
or not logical results as fast as possible and report RTE before
executed code will start some operations which cannot be finished.
Just like someone asked to delay all such tests as long as possible
because he only wanted to skip using the index created by foreign
application with unknown UDFs in KEY and FOR expressions.
In clipper this behavior depends on used RDD and different RDDs
evaluates KEY and FOR expressions first time in different places.
Similar situation is in xHarbour.

> > In SIX, it does not check the FOR expression when it opens an index file.
> > In Harbour, when you open the index file it will evaluate the FOR
> > expression, and if any variables or functions in that expression are not
> > visible, the system will crash (undefined variable/function).
Not crash but generates RTE. You can catch RT errors using BEGIN SEQUENCE
statement.You are right about FOR expression. Harbour DBFCDX evaluates
index KEY and FOR expressions to test their results just after opening
index file. It's CL5.3 DBFCDX / COMIX behavior but CL5.2 DBFCDX / SIXCDX
evaluates only KEY expression when index is open and FOR is evaluated only
when index is updated.

> > eg. Index on iif(x=3,"a","b") tag "temp" of test.cdx
> > When the index is opened (set index to...) if X is not visible, Harbour will
> > crash. In Clipper, it will only crash if a row in the table changes value
> > and the index needs to be updated.
Yes but please use more precise description. RTE is not a crash but
exception which can be fully controlled by programmer. Some important
Clipper features are implemented using RTE, i.e. NETERR() or division
by 0.

> > Unfortunately, my code has lots of specialized temporary indexes that are
> > created and then used within a specific function. This does not present a
> > problem until a timer event fires, which needs to close files to do
> > "something". Upon reopening those file before RETURNing back the original
> > function, the system crashes because the FOR in the index has variables out
> > of scope.
> > I can rewrite these but I will probably have to use Private variables and
> > non-Static functions.
I'll change early expression evaluation in Harbour SIXCDX driver only
so Harbour SIXCDX will work like CL52 DBFCDX / SIX3 SIXCDX and
Harbour DBFCDX will work like CL53 DBFCDX / COMIX verifying both KEY
and FOR expressions when index is opening.

I'll commit it in a while. You should take current Harbour SVN and
rebuild the compiler binaries.

best regards,
Przemek

On Wed, 03 Feb 2010, smu johnson wrote:

Hi,

> > Thanks Przemek.
> > Could you post back here when I should get the SVN etc?
It's already ready in SVN.
I committed it few minutes after I sent you the message.
Look at the ChangeLog:

2010-02-03 11:15 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/src/rdd/dbfcdx/dbfcdx1.c
! do not verify FOR expression just after loading new index file
in SIXCDX RDD. It's CL52 DBFCDX / SIX3 SIXCDX compatible behavior
but Harbour DBFCDX and CL53 DBFCDX / COMIX verifies both KEY and
FOR expressions when index is loaded.
! fixed RTE numbers to be CL53 compatible when index with wrong
(returning wrong results) KEY or FOR expression is loaded.

also the problem with FILEATTR() is already fixed:
2010-02-02 17:58 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)

anyhow you may want to look at:

HB_FGETATTR( <cFileName>, @<nAttr> ) -> <lSuccess>
HB_FSETATTR( <cFileName>, <nAttr> ) -> <lSuccess>

and maybe:

HB_FSETDATETIME( <cFileName>, [<dDate>], [<cTime HH:MM:SS>] ) -> <lSuccess>
HB_FSETDATETIME( <cFileName>, [<tTimeStamp>] ) -> <lSuccess>

HB_FGETDATETIME( <cFileName>, @<tTimeStamp> ) -> <lSuccess>
HB_FGETDATETIME( <cFileName>, @<dDate>, @<cTime> ) -> <lSuccess>

Harbour support timestamp values. You can find more information about
timestamp and other Harbour extensions in doc/xhb-diff.txt

best regards,
Przemek