A nice sample of 5333-causing code. Can anybody explain why?

ORBIT C.S. - Greece

unread,

Jan 4, 2002, 6:05:20 AM1/4/02

to

Hi all

We solved a 5333 problem that rised unexpectedly yesterday. I’m
just posting this code in case somebody could explain. Everything
happens when loading arrays from an SQLTable. We try to trap any NULL
value but in the first case under certain circumstances we cant avoid
it. It’s obvious that the 2nd code is ‘better’ (we
evaluate once and than react while in the first case we use GetData
several times). I just cant understand why the 1st code can cause
problems in any case – as proved!

CODE THAT CREATES PROBLEM
*************************
AAdd(aArray, { " ",0 } )
oDS:GoTop()

DO WHILE !oDS:EOF
cName := oDS:GetData( sName )
nID := oDS:GetData( sID )

IF !IsNil(cName) .AND. !IsNil(nID )
cName := oDS:GetData( sName )
IF cName == ""
cName := " "
ENDIF
AAdd( aArray, { cName, nID } )
ENDIF
oDS:Skip()
ENDDO

ERROR FREE CODE
***************
AAdd(aArray, { " ",0 } )
oDS:GoTop()

DO WHILE !oDS:EOF
cName := oDS:GetData( sName )
nID := oDS:GetData( sID )

IF !IsNil(cName) .AND. !IsNil(nID )
cName := oDS:GetData( sName )
IF cName == ""
cName := " "
ENDIF
AAdd( aArray, { cName, nID } )
ENDIF
oDS:Skip()
ENDDO

Happy new year everybody.

Stavros Spanos

Malcolm Gray

unread,

Jan 4, 2002, 6:30:22 AM1/4/02

to

"ORBIT C.S. - Greece" <s...@orbit.gr> wrote in message
news:f736baef.02010...@posting.google.com...

> Hi all
>
> We solved a 5333 problem that rised unexpectedly yesterday. I’m
> just posting this code in case somebody could explain. Everything
> happens when loading arrays from an SQLTable. We try to trap any NULL
> value but in the first case under certain circumstances we cant avoid
> it. It’s obvious that the 2nd code is ‘better’ (we
> evaluate once and than react while in the first case we use GetData
> several times). I just cant understand why the 1st code can cause
> problems in any case – as proved!

I am probably missing something but can you highlight
the differences between the two cases of code because I am having trouble
spotting them.

ORBIT C.S. - Greece

unread,

Jan 4, 2002, 9:19:14 AM1/4/02

to

Sorry, there was a small error. Code is as follows:

CODE THAT CREATES PROBLEM
*************************
AAdd(aArray, { " ",0 } )
oDS:GoTop()

DO WHILE !oDS:EOF
cName := oDS:GetData( sName )
nID := oDS:GetData( sID )

IF !IsNil(oDS:GetData( sName )) .AND. !IsNil(oDS:GetData( sID ))

cName := oDS:GetData( sName )
IF cName == ""
cName := " "
ENDIF
AAdd( aArray, { cName, nID } )
ENDIF
oDS:Skip()
ENDDO

ERROR FREE CODE
***************
AAdd(aArray, { " ",0 } )
oDS:GoTop()

DO WHILE !oDS:EOF
cName := oDS:GetData( sName )
nID := oDS:GetData( sID )

IF !IsNil(cName) .AND. !IsNil(nID )
IF cName == ""
cName := " "
ENDIF
AAdd( aArray, { cName, nID } )
ENDIF
oDS:Skip()
ENDDO

The difference is that in the right code the values are stored in
variables and than handled, while in the erroneous case we use GetData
extensivelly.

Stavros

Jamal

unread,

Jan 4, 2002, 10:11:21 AM1/4/02

to

Stavros,

May be you should test for !Empty(...) not is IsNil(...)

HTH,
Jamal

"ORBIT C.S. - Greece" <s...@orbit.gr> wrote in message
news:f736baef.02010...@posting.google.com...

Geoff Schaller

unread,

Jan 4, 2002, 6:15:54 PM1/4/02

to

Jamal's on the right track.

You don't show us the most important bit of code - how strongly typed are
these local variables? What are your compiler settings? You have to remember
that all sorts of type casting defaults occur, especially when you read from
a DBF. NIL values get converted to a default of the correct data type - you
never get NIL when the field is treated as a Usual. Hence this is why your
tests against the actual field are less accurate. They are converted to a
datatype and hence the default for that data type.

geoff

"ORBIT C.S. - Greece" <s...@orbit.gr> wrote in message
news:f736baef.02010...@posting.google.com...

- Jari -

unread,

Jan 4, 2002, 7:32:59 PM1/4/02

to

Stavros,

> You don't show us the most important bit of code - how strongly typed are
> these local variables? What are your compiler settings?

These shouldn't make any difference, if second sample works.

> You have to remember
> that all sorts of type casting defaults occur, especially when you read from
> a DBF. NIL values get converted to a default of the correct data type - you
> never get NIL when the field is treated as a Usual.

This is true only working with values coming from DBF files or in SQL (which you are using
I think?) SQLSELECT:NullAsBlank is set true. Otherwise in SQL you get NIL for all fields
with values NULL.

REMARK NullAsBlank is implemented very poorly in SQL classes, don't trust it!

> Hence this is why your
> tests against the actual field are less accurate. They are converted to a
> datatype and hence the default for that data type.

They shouldn´t create any problems here.

Can you tell us about the variable typing and also
what SQL datatypes are fields where you are referring?

Basically I don't see anything wrong in your code.

Often these 5333 disappear or move by code change, but the real reason
might be in totally different place.....these GetData calls might just
do that, since they execute lot of code...GC might kick in.

Have you defined....this key to registry...or if you have VOPP do you
have VOPP Plus - CA-VO General Settings - Clear released memory - > enabled

Here is .reg file for it:
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\ComputerAssociates\CA-Visual Objects Applications\Runtime]
"WipeDynSpace"=dword:00000001

It might give you 5333 faster if problem is somewhere else.

- Jari -

ORBIT C.S. - Greece

unread,

Jan 5, 2002, 2:19:30 PM1/5/02

to

No, no Jamal the test is ok, and this code worked - and works - ok for
5 years now. Also we have had the problem with null values in arrays
in the past , so we know how to deal with it. The strange think here
is that variables assignment makes things more stable so GC doesnt
fetch the problem under certain conditions. We discovered the problem
when delivering maintanance code for an app. The problem happened
allways, but not if we disturbed the process with msgboxes for
debugging reasons - another clue of typical 5333 problems.

ORBIT C.S. - Greece

unread,

Jan 5, 2002, 2:40:18 PM1/5/02

to

Jari, Geoff hello

> Can you tell us about the variable typing and also
> what SQL datatypes are fields where you are referring?

Datatypes are typical VARCHAR in SQL7. So no problem with this. Also
the variables are defined as STRING. The problem occurs when a value
of "" is passed in the array. Thats why we do all the checks before.
In fact in SQL you have more possibilities of NULL values because of
the datatypes.

My question is why the first code is worse than the second. Both
should work ok.

> Often these 5333 disappear or move by code change, but the real reason
> might be in totally different place.....these GetData calls might just
> do that, since they execute lot of code...GC might kick in.
>

I agree with this. Also I'm afraid that internal SQLTable() problems
might interfear with this problem. The certain table has a TEXT field
(memo), but I'm not dealing with it at this part. In fact when we used
SQLSelect() to get the specifique values we didnt have the problem.

> Have you defined....this key to registry...or if you have VOPP do you
> have VOPP Plus - CA-VO General Settings - Clear released memory - > enabled
>
> Here is .reg file for it:
> Windows Registry Editor Version 5.00
>
> [HKEY_CURRENT_USER\Software\ComputerAssociates\CA-Visual Objects Applications\Runtime]
> "WipeDynSpace"=dword:00000001
>
> It might give you 5333 faster if problem is somewhere else.
>

This is really interested Jari. What does it do ? Where can I find
documentation about it ?

Cheers

Stavros

Geoff Schaller

unread,

Jan 5, 2002, 7:41:09 PM1/5/02

to

Stavros,

> when delivering maintanance code for an app. The problem happened
> allways, but not if we disturbed the process with msgboxes for
> debugging reasons - another clue of typical 5333 problems.

Very interesting comment.

I also sometimes found that even work with serial comms and 3rd party
controls, we could make certain errors disappear just by inserting
OutputDebugString() commands! In other words, we put the calls in to inspect
the values and they showed what we needed and the code worked. Remove the
calls and it failed!

Hence we left them in <g>.

Geoff

nico

unread,

Jan 6, 2002, 5:06:38 AM1/6/02

to

> we could make certain errors disappear just by inserting
> OutputDebugString() commands! In other words, we put the calls in to inspect
> the values and they showed what we needed and the code worked. Remove the
> calls and it failed!

Same kind of thing happenned in one of my app. It was by using the
terminal lite window. At the end, I had to link the Terminal Lite
library. (I was not using OutputDebugString() at that time )

Nico

- Jari -

unread,

Jan 6, 2002, 6:18:07 PM1/6/02

to

Stavros,

> > [HKEY_CURRENT_USER\Software\ComputerAssociates\CA-Visual Objects Applications\Runtime]
> > "WipeDynSpace"=dword:00000001
> >
> > It might give you 5333 faster if problem is somewhere else.
> >
>
> This is really interested Jari. What does it do ? Where can I find
> documentation about it ?

Here is sample which will tell you how good it is. It is actually
from head translation of Rod's sample (Thanks Rod and SDT)
in some SDT magazine.

Read this carefully it will make life with unhandled error much easier....

FUNCTION Start()

// If WipeDynSpace is disabled you should be able to run this
// whole stuff without errors

// If WipeDynSpace is enabled you will get unhandled error

LOCAL o AS OBJECT
LOCAL p AS PTR

//Initialize whatever object
o := Hyperlabel{ #TEST , "Test" , "Test Description" }

//Make duplicate of objects pointer address
p := PTR( _CAST , o )

//Both pointers in same address
? PTR( _CAST, o ) , " - " , p

// Call object to do something
? o:Description

// Cast duplicate pointer to object and do something
? OBJECT( _CAST , p):Description

// Force dynamic memory collection
CollectForced()

//Pointers not the same anymore as CollectForced was called!
? PTR( _CAST, o ) , " - " , p

// Call object in new address to do something - OK
? o:Description

// Cast duplicate pointer to object and do something - NOT OK anymore

// REMARK: Allthough by setting WipeDynSpace disabled you should be
// able to run this sample without problems, you will get problems
// in real life, when app continuos

// If WipeDynSpace is enabled this line will cause GPF since
// Collectforced really cleaned the space and moved the dynamic
// object pointer to another address

? OBJECT( _CAST , p):Description

_wait()

- Jari -

unread,

Jan 6, 2002, 6:24:24 PM1/6/02

to

Stavros,

> > [HKEY_CURRENT_USER\Software\ComputerAssociates\CA-Visual Objects Applications\Runtime]
> > "WipeDynSpace"=dword:00000001

Excuse me I forgot....

Disable (Default) value dword:00000000

No zeroed memory for released dynamic memory

Enabled value dword:00000001

Zeroed memory for released dynamic memory

- Jari -

Geoff Schaller

unread,

Jan 7, 2002, 3:02:50 AM1/7/02

to

What I "think" happens is that some cleanup mechanism is only being tripped
because of these additional runtime calls. Documenting these kinds of things
does help the dev team track down problems.

"nico" <ni...@microsurveys.co.uk> wrote in message
news:fde4aab8.02010...@posting.google.com...