Wow, great answer. Maybe I should stop using SIX3 entirely. Any other
Harbour compatible database formats you would recommend for the transition,
to avoid all these bugs? Hopefully it isn't hard to convert SIX3 to
whatever you suggest. If I can keep using a file-based database instead of
having to connect to a Mysql server for example, that would obviously be
more convenient for what I am doing.
Also,
> It should be add only to INDEX ON command which create index with key
> expression starting with "sxChar(", "sxNum(", "sxDate(" or "sxLog(".
> That's all.
I changed:
index on sxChar(11) tag "Keyword" of (fTemp)
To:
index on sxChar(11) tag "Keyword" of (fTemp) EMPTY
... and the problem doesn't come back! :) I tried to follow your
instructions as best I could. Did I do it correctly? (I just want to
double check)
Thank you!!! By the way, you really know your stuff about Clipper!
2010/1/28 Przemysław Czerpak <dru...@acn.waw.pl>
> On Thu, 28 Jan 2010, smu johnson wrote:
>
> Hi,
>
> > I appreciate the answer. I don't like hacks either, as I have found some
> > other hacks that I've had to try to work around. I wrote the EMPTY thing
> > (as we do use the .ch file) and it solved the problem! So thanks for
> that.
> > As far as the question of if you want to implement SIX3 defaults... you
> > would know a lot better than I would if it's a good idea.
>
> Please only remember that it should not be used for normal indexes.
>
> > I will say one
> > thing though, it will help Clipper programmers who have had a hard time
> > getting SIX3 to work back 10 years ago and have stumbled upon it "just
> > working" back then...
> > Since Harbour seems to be 100% Clipper compliant, I would think it would
> be
> > a good idea. But then again, I don't like hacks either :( So it is
> really
> > your call.
>
> SIX3 RDDs are not Clipper part. I know that they are very popular and
> I also have SIX3.02 package but when I begin to make deeper tests with
> this library I've found such many serious bugs that in my opinion it
> was never fully production ready. Buffer overflows, memory corruptions,
> index file corruption, memo and data file corruptions, wrongly updated
> index files, problems with accessing some valid indexes files, etc.
> I can understand that someone make a mistake and the code should be
> fixed but in few cases they intentionally introduced hacks which cannot
> work and _HAVE_ to give wrong results and this causes that I stop to
> trust Successware and their products. This code quite well illustrate it:
>
> request SIXCDX
> proc main()
> field FINT
> rddSetDefault( "SIXCDX" )
> dbcreate( "_tst", { { "FINT", "V", 4, 0 } } )
> use _tst
> dbappend()
> FINT := 538976287; ? FINT
> FINT := 538976288; ? FINT
> FINT := 538976289; ? FINT
> return
>
> This code compiled by Clipper and linked with SIX3 SIXCDX RDD shows:
> 538976287
> 0
> 538976289
> Funny isn't it?
> What is amazing in 538976288 number that it cannot be stored in V4
> fields giving 0 as result?
> Its binary representation is equal to space(4) and spaces are used
> as default initialization value in DBF record. It means that someone
> hacked in SIX3 code that exactly this value (538976288) when read from
> DBF record is translated to 0. He had to know that such hack breaks
> this field usage and it's a bug which can cause very serious problems
> for users. But it is very hard to locate such bug for normal users who
> do not know what should be tested so it was not creating SIX3 selling
> problems and was accepted in the final product. Maybe they didn't have
> wrong motivation but in my opinion such things should never happen.
>
> Some anomalies which are not critical I replicated in SIXCDX and HBSIX
> library but for sure I cannot replicate hacks like above only to be
> bug compatible. In case of Clipper I usually try to document all anomalies
> but there are too much problems with SIX3 library to address all of them
> so it would be waste of time.
>
> > One last question though, if I may. How often do I have to worry about
> this
> > EMPTY / CUSTOM addition? Is it just whenever I want to use sx_keyadd?
> Or
> > are there other pitfalls I should look out for.
>
> It should be add only to INDEX ON command which create index with key
> expression starting with "sxChar(", "sxNum(", "sxDate(" or "sxLog(".
> That's all.
>
> best regards,
> Przemek
> _______________________________________________
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
smu johnson <smujohn...@gmail.com>
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
