5333 error by SetselectiveRelation
Roland Wäfler
nach langem suchen konnte ich einen 5333 Fehler der mich schon seit
Wochen quält eingrenzen.
I 5333 error treated my since many weeks.
Now I think to know it results from an setselectiverelations beetwen 2
Dbservers (CDX).
After some skip's the application crashs.
SELF:OwnerWin:Server:SetSelectiveRelation(SELF:oSFWLager2:Server,{||(_Field->W_ID*10000)+_Field->Jahr})
When I change the codeblock by #W_ID the error is gone. (Could not be
the solution because then never found a child).
W_ID ist defined numeric 5
Jahr numeric 4
Has anbody made the same experiencies?
Could anybody give my a hint what I have to do to clear the problem?
With best Easter wishes
Roland
Stephen Quinn
Usually you relate FIELDS not the results of EXPRESSIONS
- the relationship matches the contents of the fields
Eg
// Assuming W_ID is a field in both Servers
SELF:OwnerWin:Server:SetSelectiveRelation(
SELF:oSFWLager2:Server,{||_Field->W_ID} )
If you only want certain records in the CHILD then use a FILTER after
setting the relation
Eg
SELF:oSFWLager2:Server:SetFilter( {||_FIELD->W_ID * 10000 + _FIELD->JAHR } )
Although I can't seeing the above work as the relation is on W_ID but your
trying to see W_ID*10000 + etc... which won't even be in the relations
scope.
Eg
W_ID = 50
Relation is 50=50
Your trying to see if 50 = 50*10000 + whatever is in JAHR
HTH
Steve Quinn
Geoff Schaller
I agree with Steve. Your SetSelectiveRelation does not make lexicle sense.
It must return a valid "field" reference - numeric, string, symbol or an
array of such and your code block "might", but then it might not. Worse
still, it might "sometimes".
Geoff
"Roland Wäfler" <wae...@gmx.net> wrote in message
news:be0e990f.02033...@posting.google.com...
Geoff Schaller
"Geoff Schaller" <geof...@bigpond.net.au> wrote in message
news:Whsp8.2779$hi7....@news-server.bigpond.net.au...
Couchman
Happy Easter to you too.
I don't see why your code produces an error. While the linking expression is a little unusual, I believe
it's legal.
You might try a small app to isolate the problem. Here's one I put together to try your code out.
FUNCTION Start
LOCAL oDB1 AS DBServer
LOCAL oDB2 AS DBServer
// db1 structure: W_ID N5, JAHR N4
oDB1 := DBServer{"d:\temp\db1",DBSHARED,DBREADWRITE,"DBFCDX"}
// db2 structure: LINK N10
// indexed on LINK
oDB2 := DBServer{"d:\temp\db2",DBSHARED,DBREADWRITE,"DBFCDX"}
oDB1:SetSelectiveRelation(oDB2,{||_FIELD->W_ID * 10000 + _FIELD->JAHR})
oDB1:GoTop()
DO WHILE .NOT. oDB1:EoF
? oDB1:FIELDGET(#W_ID),oDB1:FIELDGET(#JAHR)
DO WHILE .NOT. oDB2:EoF
? Space(4),oDB2:FIELDGET(#LINK)
oDB2:Skip()
ENDDO
?
oDB1:Skip()
ENDDO
oDB1:Close()
oDB2:Close()
_wait()
RETURN NIL
hth's
Richard
Couchman
I disagree with your statements. The codeblock in SetSelectiveRelation needs to
return a value that the child workarea can be scoped by. That can be a field,
an expression, a constant - it doesn't matter. The string, symbol, or array
that SetSelectiveRelation will accept as the second parameter are just shortcuts
for creating the codeblock.
Roland's codeblock always returns a numeric value when evaluated. As long the
controlling index in the child workarea has numeric key values, it ought to
work.
Regards,
Richard
Geoff Schaller
Thats is EXACTLY what I said - let me quote me <g>.
> > It must return a valid "field" reference - numeric, string, symbol or an
> > array of such and your code block "might", but then it might not. Worse
What I was drawing attention to was the fact that we don't know what the
code block evaluates to and we need to see this to be certain that the
resulting numeric is in fact a legal value as a field rerefence. If its not,
I expect the behaviour he is seeing.
Geoff
"Couchman" <rcou...@ix.netcom.com> wrote in message
news:3CA67CB1...@ix.netcom.com...
> Hi Geoff
>
> I disagree with your statements. The codeblock in SetSelectiveRelation
needs to
> return a value that the child workarea can be scoped by. That can be a
field,
> an expression, a constant - it doesn't matter. The string, symbol, or
array
> that SetSelectiveRelation will accept as the second parameter are just
shortcuts
> for creating the codeblock.
>
> Roland's codeblock always returns a numeric value when evaluated. As long
the
> controlling index in the child workarea has numeric key values, it ought
to
> work.
>
> Regards,
> Richard
>
> Geoff Schaller wrote:
>
> > Roland,
> >
> > I agree with Steve. Your SetSelectiveRelation does not make lexicle
sense.
Roland Wäfler
I try to explain why I made this kind of relation.
The topic is a winecellar-software.
The main relation is beetwen 3 DBServers
1. wine
Unique-Key : W_ID numeric 5
2. wine-year
Unique-Key: W_ID numeric 5, and Jahr numeric 4
created : "W_ID*10000+JAHR"
(Jahr means Year)
3. cellar
Unique-Key: W_ID numeric 5, and Jahr numeric 4, and FL_ID numeric 2
(FL_ID is the ID of the Bootlesize)
one other order is : W_ID numeric 5, and Jahr numeric 4
created : "W_ID*10000+JAHR"
The relation with the Problem now is beetwen wine-year and cellar.
SELF:OwnerWin:Server:SetSelectiveRelation(SELF:oSFWLager2:Server,{||(_Field->W_ID*10000)+_Field->Jahr})
SELF:OwnerWin:Server: <- This is the wine-year
SELF:oSFWLager2:Server <- This is the cellar
In the datawindow should now shows for one wine-year all the
quantities in stock.
Example:
Chateau Margeaux 1996
- 15 bottles 0.75 litre
- 6 bottles 0.375 litre
- 1 bottle 1.5 litre
Wine-cellar: W_ID = 44, Jahr = 1996
Index expression 441996 ((44+10000)+1996)
I decided to work with this kind of indexing for many years as a
beginner with VO. Maybe there are better methods today?
Solong, in the appication this system works well. My application has
since long sometime problems with 5333 error.
I correct many sourcecode lines with hints out of this group but the
5333 treats my again.
After long search with DynLock() and unlock I have found the
SetselectiveRelation as the source of the problems.
Why it make this problems is for my not clear.
Could be that internal the addition is made with floats who produced
this 5333'er ?
Regards
Roland
Roland Wäfler
I also don't see any reason why the code should produce an error.
Also the error appears after 20-40 skips and skips(-1).
Regards
Roland
Couchman <rcou...@ix.netcom.com> wrote in message news:<3CA674A0...@ix.netcom.com>...
Geoff Schaller
Are the values all valid? Could you not write out the values to a log file
and inspect them for validity afterward? The other thing I'm worried about
is scope. My suggestion is to evaluate the code block first and then pass
the result to the selective relation. Where the expression is to be
evaluated and passed as a parameter it is always adivisable to execute the
expression first and only pass the result. Such code is much easier to
debug.
But yes, this is a very unorthodox method of indexing. It is not "intuitive"
and I think I would prefer a more conventional approach. That is is not to
say that your way does not work, I am just less comfortable with it.
Geoff
"Roland Wäfler" <wae...@gmx.net> wrote in message
news:be0e990f.0203...@posting.google.com...
Couchman
Geoff Schaller wrote:
> Richard,
>
> Thats is EXACTLY what I said - let me quote me <g>.
>
> > > It must return a valid "field" reference - numeric, string, symbol or an
> > > array of such and your code block "might", but then it might not. Worse
>
> What I was drawing attention to was the fact that we don't know what the
> code block evaluates to and we need to see this to be certain that the
> resulting numeric is in fact a legal value as a field rerefence. If its not,
> I expect the behaviour he is seeing.
We know EXACTLY <g> what the codeblock evaluates to. That would be the product
of W_ID and 10000, plus JAHR. If that value is present in any keyvalues of the
child workarea, you'll see those records in the scope. If not, the child
workarea appears empty after the scope.
What would be an example of W_ID and JAHR that produces an illegal value, and
result in a 5333 error?
Thanks,
Richard
Geoff Schaller
NO !!!! <g>
The codeblock must evaluate to a FIELD or field expression. This is what
will lead you to the 5333. It has nothing to do with key values. Please read
the online help for SetSelectiveRelation(). Further, if an index is active
in the child server, this expression must match the index expression fully
or partially. If there is no index active, you will have nonsense. I cannot
see your current block being anything but unstable.
Geoff
Ed Ratcliffe
I do not have a solution to your 5333 problem, but I am always nervous about
numeric fields which could easily be character fields. Is there any way you
could change the "ID" fields to character fields.
>
> Could be that internal the addition is made with floats who produced
> this 5333'er ?
>
I would not be suprised!
Ed
Couchman
Nope. You're reading more into the online help than is actually there. If you
choose to provide a codeblock, all the help file says is
<cbRelationBlock> The relation code block for the server.
If you follow through the SDK (you have a copy, don't you? <g>) the end result
of the SetSelectiveRelation is to evaluate the codeblock, and use the value to
place a top and bottom scope on the child server. Pretty straight forward.
From DBServer:Notify,
//---------------
ELSEIF lCDXSelectionActive
#IFDEF __DEBUG__
#ENDIF
VODBSelect( wWorkArea, @wCurrentWorkArea )
uVOVal:=uVOVal2:=(wSelectionWorkArea)->Eval(cbSelectionParentExpression)
VODBOrderInfo(DBOI_SCOPETOP,"",NIL,@uVOVal)
VODBOrderInfo(DBOI_SCOPEBottom,"",NIL,@uVOVal2)
//---------------
I think Roland and Ed may be pointing in the right direction - some sort of
wierdness with numeric keys.
Richard
Geoff Schaller
"might" evaluate could turn out to be nonsense. You haven't shown us your
index/tag (which even the codeblock version MUST evaluate to...) so its a
little hard to predict the outcome. As I said (and meant), this form of
selective relation is not particularly stable.
Geoff
"Couchman" <rcou...@ix.netcom.com> wrote in message
news:3CA74BA8...@ix.netcom.com...
Stephen Quinn
Maybe it's a result of the multiplication, ie floats and the garbage
collector, causing the 5333s.
HTH
Steve Quinn
"Roland Wäfler" <wae...@gmx.net> wrote in message
news:be0e990f.02033...@posting.google.com...
Roland Wäfler
the Indextag is created with
oServer:CreateOrder('IndName',cFilename,"W_ID*10000+JAHR",,FALSE)
I choosed to handle with numeric key-fields (maybe a fault) long time
ago and now the application is not as easy to convert to char
key-fields.
How you would made the index in an more common way for my
constellation (two numeric fields)?
with regards
Roland
"Geoff Schaller" <geof...@bigpond.net.au> wrote in message news:<NTMp8.5581$hi7....@news-server.bigpond.net.au>...
Ed Ratcliffe
>
> I choosed to handle with numeric key-fields (maybe a fault) long time
>
I also made that mistake early in my Clipper days. Although it was a bit
painful to create a conversion utility and make the required changes to the
app code, I consider the effort worthwhile. I have had far less trouble with
linked files and indexes since making the change. Back to the basics of
database design.. (-:
Or you could perhaps create your index with:
oServer:CreateOrder('IndName',cFilename,StrZero(W_ID, 5, 0)+StrZero(JAHR, 4,
0),,FALSE)
Ed
Geoff Schaller
Then it will work properly (obviously you filter/scope/seek accordingly).
Geoff
"Roland Wäfler" <Wae...@gmx.net> wrote in message
news:82a150ef.02040...@posting.google.com...
Roland Wäfler
I think now a lot of works is waiting to my.
With a simple coding I could reproduce the error.
I created an Index with one ordertag (my style) and one tag with your
StrZero().
With my tag an got a error after 5-10 complet loops over the servers
with the StrZero()-tag the error disappears.
do you use the StrZero with explicite length?
StrZero(var,5) or StrZero(var)
Regards
Roland
-------the coding --------------
LOCAL oDBW AS Weinstam
LOCAL oDBJ AS Jahrgang
LOCAL oDBLg AS Lager
LOCAL i, ccLoops AS DWORD
LOCAL sString AS STRING
ccLoops := 51
oDBW := Weinstam{,DBSHARED,}
oDBLg:= Lager{,DBSHARED,}
oDBJ := Jahrgang{,DBSHARED,}
//oDBLg:SetOrder('W_IDJAHR1') // Char Index
oDBLg:SetOrder('W_IDJAHR2') // numeric Index
oDBW:SetOrder('W_ID')
oDBJ:SetOrder('W_ID')
oDBW:SetSelectiveRelation(oDBJ,{|| _Field->W_ID})
oDBJ:SetSelectiveRelation(oDBLg,{||
(_Field->W_ID*10000)+_Field->JAHR})
//oDBJ:SetSelectiveRelation(oDBLg,{||
StrZero(_Field->W_ID)+StrZero(_Field->JAHR)})
FOR i:=1 UPTO ccLoops
oDBW:GoTop()
DO WHILE .not. oDBW:EOF
DO WHILE .not. oDBJ:EOF
DO WHILE .not. oDBLg:EOF
oDBLg:Skip(1)
ENDDO
oDBJ:Skip(1)
ENDDO
oDBW:Skip(1)
ENDDO
oDBW:GoBottom()
DO WHILE .not. oDBW:BOF
DO WHILE .not. oDBJ:EOF
DO WHILE .not. oDBLg:EOF
oDBLg:Skip(1)
ENDDO
oDBJ:Skip(1)
ENDDO
oDBW:Skip(-1)
ENDDO
IF i%50 = 0
IF !InCollect()
CollectForced()
ENDIF
ENDIF
NEXT
oDBW:Close()
oDBJ:Close()
oDBLg:Close()
MessageBox(0,Str(ccLoops)+' Schlaufen durchlaufen,
'+Str(TOtal),'Ende',MB_OK)
Geoff Schaller
You must fix the length. Fix it to the same width as the width of the
numeric field.
Geoff
"Roland Wäfler" <wae...@gmx.net> wrote in message
news:be0e990f.0204...@posting.google.com...
Stephen Quinn
> do you use the StrZero with explicite length?
> StrZero(var,5) or StrZero(var)
Use it with an explicit length - index keys must be the same length for
every record.
Read the help on STR() to see what applys if you don't supply the
length/decimal parameters.
HTH
Steve quinn
Phil McGuinness
evaluation.
Refer to Sandy Hoods book re filters and Numerics.
Phil McGuinness
-------------------
"Stephen Quinn" <squ...@brutecom.com.au> wrote in message
news:3cab9597$0$11450$afc3...@news.optusnet.com.au...