Hi !

My name is Karcz,  Wojciech Karcz.

I have used CLIPPER since 1996, and ALASKA since 2000 (current version
1.90.331)



A few days ago I found a "VERY VERY DEEP - HORRIFYING ERROR"  in the :=
command, or more precisely in memory buffer management of the APPEND +
REPLACE commands



In HORROR.XIP :

HORROR_MISTAKE.DOC    - description of the error, behavior and tests

HORROR.PRG

CORRECT.PRG

COLL_852.prg

DATA2013.dbf       -  INPUT data file

DATA2013.ntx

DATA2014.dbf       - OUTPUT data file

DATA2014.ntx

LESS2014.dbf          - OUTPUT data file - less mistakes

LESS2014.ntx

MORE2014.dbf        - OUTPUT data file - more mistakes

MORE2014.ntx





Please read first  HORROR_MISTAKE.DOC  !!!

IT IS VERY IMPORTANT  (not for me only -  but for ALASKA and all users of
ALASKA)  !!!





Best Regards !!!
Wojciech Karcz

WWW.DATA-SOFT.PL

Wojciech Karcz wrote:

> A few days ago I found a "VERY VERY DEEP - HORRIFYING ERROR"  in the :=
> command, or more precisely in memory buffer management of the APPEND +
> REPLACE commands

Hi,

after adding a project file and making your code more readable by adding
indention, I could not reproduce any of your errors.

If I understood corretly, in case of any problem there should be something
in the fiel "mistake" in the output file... but this is completely empty in
my case.

Maybe you should send this to Alaska support and give more information such
as what version of Xbase++ you are using, which service levels and hotfixes
you have applied (if any) and what operating system this is running on.

Thomas

Wojciech,

>A few days ago I found a "VERY VERY DEEP - HORRIFYING ERROR"  in the :=
>command, or more precisely in memory buffer management of the APPEND +
>REPLACE commands

The problem has nothing to do with the ":=" assignment operator or with 
Append -- and the only thing horrifying that I could see was your code. 

But seriously, the reason for your problem is simply your incorrect code, 
which highlights some Index optimization issues that Alaska introduced in 
Xbase++.

First, the code you posted might work in Clipper, but will not work in 
Xbase++ without at least some changes. You are opening your databases in 
Shared Mode (the default for Xbase++) instead of Exclusively (the default 
for Clipper), which means that the "ZAP" command will give a runtime error 
in Xbase++.

It also means that the Alaska runtime (the DBF and/or NTX DBEs) might not 
save data onto disk (and update file headers and record pointers) until the 
database is closed or records are unlocked or committed.

Because you don't have any code indentations (for "if"/"endif" "do"/"while", 
etc.) your code is very difficult to read. That is probably the reason why 
you missed the fact that in the "Correct" program you have no "if DbSeek()", 
so the program only changes the last record of the "Output" database!

Additionally, you also have no "Main()" Procedure or "return" command in any 
of your programs, but a whole lot of unnecessary code, switching between 
workareas and similar things. I have attached a streamlined version of the 
program that works correctly (in Clipper as well as all Xbase++ versions).

In Xbase++ 1.20.178 you would actually get a runtime error on of the first 
five or so DbSeek()s -- even if you remark out the Zap -- stating that a 
record lock is required for that operation. Alaska fixed that kind of 
over-optimization problem in later versions of Xbase++, but because your 
program opens files shared and doesn't lock or commit any records, while 
appending and changing values in the output database, the Index pointer 
gets out of synch and the Index is actually pointing to a different record 
than the database record pointer.

In Xbase++ versions 1.30.212 through 1.70.267 you will get 8 or 9 additional 
records in the output database -- instead of records being overwritten -- as 
the DbSeek() will return False (instead of True) when the Index pointer gets 
out of synch, and a record is found but the record pointer is on the last 
record instead of the correct one.

In Xbase++ versions 1.80.284 through 2.00.488 you will get the exact same 
results and the number of records will be the same as when opening the 
database in exclusive mode, but some records will be overwritten with wrong 
data, as the DbSeek() sometimes returns True, while the database record 
pointer is on the last record, rather than the one that was (supposed to be) 
found.

In short: either opening the (output) database exclusively -- as your code 
does, when compiled with Clipper -- or adding record locking (and commits) 
to the loops would fix the problem. On the other hand, the FLock() in your 
code, is completely useless and not a substitute for opening the output 
database exclusively.

Please read the Xbase++ documentation about differences to Clipper for more 
details about porting Clipper programs or sharing a common code-base between 
Clipper and Xbase++.

Hope that helps,

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas.GP@Charter.net
web:   http://www.Aerospace-History.net