Strange Behaviour in VO 2.7
Mark Chimes
I am receiving the following error when running the method below.
I am stumped as to what could be causing the problem.
Any clues?
Cheers,
Mark
Error is:
Visual Objects (Version 2.7. Build 0.2716), Version 2.7
01/04/2004 07:05:22 PM
Application: C:\MAD3\MAD3.EXE
Error message:
--------------
Error Code: 50 [ ACCESS VIOLATION ]
Subsystem: VO-CODE
Error Subcode: 5333
Argument Number: 2
Description: Application Code Error causing Access Violation
CallStack:
__OLEERRORHANDLER (Line: 0)
__WCDIALOGPROC (Line: 0)
__WCCONTROLPROC (Line: 0)
_CHECKWINDOW (Line: 0)
_GTWRITECON (Line: 0)
Error Object created:
--------------------
SubSystem :VO-CODE
SubCode :5333
GenCode :Access Violation
ExceptionCode :02CF248402CF2488
ExceptionFlags :00000000
ExceptionAddress:00386169
ParamNumber :2
ExceptionInfo :00000000
Severity :2
CanDefault :.F.
CanRetry :.F.
CanSubstitute :.F.
Operation :
Description :Application Code Error causing Access Violation
FileName :
Tries :0
FileHandle :0
SubCodeText :
Arg :
ArgTypeReq :NIL
MaxSize :0
SubstituteType :NIL
CallFuncSym :
--------------------
Here is the code that causes the error.:
do while ! self:server:EOF
if self:server:TAG <> "I"
if self:server:FINANCIAL < cYear
self:server:TAG := "I"
endif
if self:server:ASSOCFINYR < cYear
self:oDCcNAME:Value := AllTrim(self:server:FIRSTNAME) + " " +
self:server:SURNAME
self:server:AssocActiv := .F.
endif
endif
self:server:Skip()
enddo
self:server:Commit()
self:server:Close()
Jamal Assaf
Although I can't see anything wrong with your code, I'd try the following:
1. Have you tried to turn debugging info like Proline and ProName and step
thru the code in the debugger?
2. Also, whenever I get and set server values, I use the DBServer methods
FIELDGET( ) and FIELDPUT( ), instead of using the fieldname directly:
for example:
SELF:SERVER:FIELDGET(#FINANCIAL)
SELF:SERVER:FIELDPUT(#FINANCIAL, cWhatever)
It has less OO runtime overhead and better runtime checking.
3. Try to print retrieved and see if any value are returning corrupted or
NIL values.
HTH,
Jamal
"Mark Chimes" <verac...@hotmail.com> wrote in message
news:c4gmec$2idnk9$1...@ID-79269.news.uni-berlin.de...
Paul De Bie
two things to check...
a) cYear is it still in scope?
b) you are assigning a value to self:oDCcName (which I assume is an SLE on
your window?) Why do you do this in side the DO-loop? Once is enough I'd
say...
HTH
Paul
"Mark Chimes" <verac...@hotmail.com> schreef in bericht
news:c4gmec$2idnk9$1...@ID-79269.news.uni-berlin.de...
Mark Chimes
Thanks, I will make the changes you suggest and see if it makes any
difference.
cheers,
Mark
"Jamal Assaf" <RemoveThi...@yahoo.com> wrote in message
news:c4gp3v$2gt8jl$1...@ID-203539.news.uni-berlin.de...
Mark Chimes
cYear holds a static value that is used to check against a year value within
each record. The current scope is the whole DBF.
I am assigning to the SLE each loop through the DBF as the client wanted to
see the name of the customer displayed each time something was changed on a
record. Otherwise your comment holds true <g>
Something I forgot to mention, the process falls over in a different place
each time. There is no consistency to its failure.
cheers,
Mark
"Paul De Bie" <paul....@CLEARTHIShnt.be> wrote in message
news:406bfe77$0$1978$ba62...@news.skynet.be...
Mark Chimes
More information on this error...
When the error occurs it is often in the following format.
Terminal Lite/32: AppName
The instruction at "0x77f8b812" referenced memory at "0x03bd0030". The
memory could not be "read".
Click on OK to terminate the program.
The strange thing is that sometime the routine complete successfully, most
times it does not.
When the program bombs on my computer, I can see the errors.
When I run the program on the client's Terminal Server, the program crashes
completely and returns to the desktop.
Any help appreciated <g>
cheers,
mark
"Mark Chimes" <verac...@hotmail.com> wrote in message
news:c4gmec$2idnk9$1...@ID-79269.news.uni-berlin.de...
Jamal Assaf
You can such unpreditable behavior if memory somehow got corrupted or you
did a mis-allocation in your some other code up in the code chain. Are you
declaring structures or allocating memory?
Could a corrupt repository be the cause? Is possible you can produce a small
sample to duplicate the problem.
Have you tried DynLock() DynUnlock() around the code?
"Mark Chimes" <verac...@hotmail.com> wrote in message
news:c4ibtf$2ji7nb$1...@ID-79269.news.uni-berlin.de...
Karl Faller
FWIW,
>The instruction at "0x77f8b812" referenced memory at "0x03bd0030". The
>memory could not be "read".
>Click on OK to terminate the program.
using my Banking Software, etc. - i suspect the problem rather to be
in the OS (XO Home in my case) than in any app.
Karl
Mark Chimes
I, too, thought it might be my system, but the problem exists on two client
systems as well.
When I run the routine over and over again, it completes successfully about
2 in every 10 times. The remaining 8 times the process will abort between
5% and 25%.
This really has me stumped.
cheers,
Mark
"Karl Faller" <100725Mask...@ASSEScompuserve.com> wrote in message
news:i66q609oc6eu9s3ii...@4ax.com...
Mark Chimes
I am declaring no structures or allocating memory. I pulled the routine out
of my app and even when I run it separately, the same behaviour exists.
There is no other code, apart from the standard stuff to call from the menu,
etc.
I have not used DynLock or DynUnlock but I will give try this and let you
know how I get on.
cheers,
Mark
"Jamal Assaf" <RemoveThi...@yahoo.com> wrote in message
news:c4ij00$2iu5b2$1...@ID-203539.news.uni-berlin.de...
Timothy Shea
Try :-
self:server:Commit()
self:server:Skip()
enddo
self:server:Close()
for the last few lines. ie. commit before skip.
Never know. Nothing else seems to work!!
Regards,
Tim
"Mark Chimes" <verac...@hotmail.com> wrote in message
news:c4gmec$2idnk9$1...@ID-79269.news.uni-berlin.de...
Mark Chimes
How's things?
The strange thing about this little routine is that it works fine about 20%
of the time. The other 80%, it falls over at varying stages through the
routine. There seems to be no rhyme or reason to it.
I finally got it to run properly once on the customer data, which has got
them out of trouble (until this time next year) <g> By that time the VO 2.7
patch will have been released and all the DBServer issues will have been
fixed, and maybe whatever caused this problem will have been cleaned up in
the process.
cheers,
Mark
"Timothy Shea" <T...@ampljunk.com.au (remove junk)> wrote in message
news:xrrcc.4850$KS1.2...@nasal.pacific.net.au...
Geoff Schaller
You don't give us much detail... Was in the index involved, do any of
these fields belong to the index expression, what else is going on and
which line causes the problem! It would help if you turned debugging
info on.
Geoff
David Dupuy
This problem could be caused by oportunistic locking either in your
code or in the OS. Seems I had a similar issue and resolved it by
using my own locking routines.
hth
David
Geoff Schaller
I think you mean optimistic locking.
Opportunistic locking is a network feature of your OS and cannot be
affected one way or other by your code. Record locking at the class
level overrides optimistic locking models of the DBServer class. Setting
the mode to ccNone disables optimistic locking.
Geoff
"David Dupuy" <da...@microstrategies.com.au> wrote in message
news:4a423206.04040...@posting.google.com:
David Dupuy
> Dave,
>
> I think you mean optimistic locking.
>
> Opportunistic locking is a network feature of your OS and cannot be
> affected one way or other by your code. Record locking at the class
> level overrides optimistic locking models of the DBServer class. Setting
> the mode to ccNone disables optimistic locking.
>
> Geoff
>
Thanks for the assist, but I assume a certain level of intelligence in
this ng. (No comments please, I don't want to be proven wrong. <g>) I
think the generic term "opportunistic" is valid and affords the
recipient enough to explore the possibilities.
David
Mark Chimes
Thanks for the comment.
This routine works perfectly every time in VO 2.6. It is only in 2.7 that
this issue has occurred.
On the matter of Opportunistic/Optimistic locking, I am reluctant to change
settings that have worked fine for over 2 years.
There is no reference (that I can find) to changes in the behaviour of these
locking mechanisms in the VO documentation that came with 2.7. (Indeed, I
would expect there to be none as this is OS territory).
cheers,
Mark
"David Dupuy" <da...@microstrategies.com.au> wrote in message
news:4a423206.04040...@posting.google.com...
Mark Chimes
I cannot give you any more details because there are none. <g>
The code I included previously is ALL the code. No index involved. It is a
very simple routine and I am at a loss to understand why the behaviour is so
inconsistent.
The application bombs - there is no VO error, no Procline, etc provided.
The inconsistent behaviour occurs both on my computers and the client
computers, but as mentioned, only in 2.7 code. I have had this little
routine working in 2.5 and 2.6 for years. (Mind you, it is only run once,
maybe twice a year).
cheers,
mark
"Geoff Schaller" <geoff...@softwarenospamobjectives.com.au> wrote in
message news:lexcc.591$8P2...@news-server.bigpond.net.au...
Jamal Assaf
Have you tried the DynLock(), DynUnlock()?
What if you throw a Collect() in the loop after certain number of
iterations?
What application runtime settings do you have in effect (Application
Properties), ie, overflow, etc?
Could you produce a small aef sample with related files that exhibits the
problem?
Jamal
"Mark Chimes" <verac...@hotmail.com> wrote in message
news:c528uj$2mve6e$1...@ID-79269.news.uni-berlin.de...
Paul De Bie
just some more thoughts...
- does it bomb out after a specific number of records processed?
- maybe always on the same record?
(put a counter in the loop and output it somewhere so you know)
- have you tried not outputting to an SLE but to, say a fixed text caption?
- and what if you step through the loop in the debugger?
¨
Paul
"Mark Chimes" <verac...@hotmail.com> schreef in bericht
news:c4gmec$2idnk9$1...@ID-79269.news.uni-berlin.de...
> Hi All,
>
> I am receiving the following error when running the method below.
> --------------
> Error Code: 50 [ ACCESS VIOLATION ]
Geoff Schaller
That is not even close to ALL of the code <g>. Nowhere in this is the
instantiation of the server, for example. An access violation is
generally you accessing an ivar or method off an object which no longer
has a valid pointer. Your server has gone so now you need to find out
why.
Geoff
"Mark Chimes" <verac...@hotmail.com> wrote in message
news:c528uj$2mve6e$1...@ID-79269.news.uni-berlin.de:
Mark Chimes
- It does not bomb out on the same record. The process crashes anywhere
between 3% and 99%.
- I have tried with no output to the SLE (ie: no output at all), output to
Fixedtext, output to a console (? command) window - no difference.
- I have not stepped thru the debugger because the first time I tried it I
got sick of looping thru 85,000 records.
The errors I am getting are NOT VO errors.
cheers,
Mark
"Paul De Bie" <paul....@CLEARTHIShnt.be> wrote in message
news:4074f5f9$0$1994$ba62...@news.skynet.be...
Mark Chimes
OK, so not ALL the code<g>, but pretty much all that is important.
The only other code is produced by VO in its own classes. The server, in
this case, is created via an entry in the WED becoming self:server, and
therefore resides in the init() method created by VO. Maybe not the best
way of going about things (normally I do tis in the post or pre-init, but I
wanted things as standard as possible to try to eradicate any issues with my
code),
An access violation is not the normal error I am receiving. Normally the
things bombs out with a Windows memory error (see previous post for exact
contents of this error).
cheers,
Mark
PS. Happy Easter!
"Geoff Schaller" <geoff...@softwarenospamobjectives.com.au> wrote in
message news:nEadc.192$ED...@news-server.bigpond.net.au...
Geoff Schaller
> OK, so not ALL the code<g>, but pretty much all that is important.
> The only other code is produced by VO in its own classes. The server,
No - you're hiding something <g>. Sorry, but if you get this kind of
error (as further detailed in your other post) you are DEFINITELY doing
something wrong. Perhaps you'd like to knock up a little appp to
demonstrate this and send it to me?
> An access violation is not the normal error I am receiving. Normally
> the things bombs out with a Windows memory error (see previous post
> for exact contents of this error).
Further evidence you are doing something naughty <g>.
Geoff
PS - going fishing for 5 days over Easter. The weather is totally
beautiful down here this time of year and the schnapper is on the go
April/May. Also quite a bit of whiting and always flathead. (sheesh!
...the temptation to refer to some Gosford residents here is
overwhelming but I'll resist <g>)
Gary Stark
Quotes rearranged to enable lunacy.
>> > An access violation is not the normal error I am receiving. Normally
>> > the things bombs out with a Windows memory error (see previous post
>> > for exact contents of this error).
>>
>> Further evidence you are doing something naughty <g>.
>>
>> something wrong. Perhaps you'd like to knock up a little appp to
>> demonstrate this and send it to me?
Which of course is further evidence that he's doing something naughty!
--
g.
Gary Stark
gst...@Redbacksweb.com
http://www.Redbacksweb.com
The trouble with political jokes is they get elected
Marshall Rhinehart
I'd double check in the directory where your opening this file that there
isn't a file that it could be trying to open as an index.
Having an instance variable with the name 'server' would make me nervous.
Granted, shouldn't be a problem, but then again....this code looks like it
should run. Even the variable TAG...this is a fieldname? Again...maybe I'm
boring... but I avoid anything at all that I think the 'system' might look
at as having another purpose.
I hesitate to reply with an 'unresearched' answer (running 2.6 here). But
this is where I'd start.
Hope you figure this out.
Marshall
"Mark Chimes" <verac...@hotmail.com> wrote in message
news:c4gmec$2idnk9$1...@ID-79269.news.uni-berlin.de...
Marshall Rhinehart
You mention a fair amount of variability with this problem. Just a thought,
but your updating the screen each time through the loop. How long does this
run? If the screen saver kicks in, how does it handle the refresh? I've
seen some odd behavior (nothing as drastic as your problem) when the screen
saver comes on, and I'm updating an SLE like you are. Perhaps that would
lead to an error your describing as being 'nonVO'?
Alright...back to my own bugs... <g>
Marshall
Mark Chimes
This routine takes about 15 minutes to run (if it completes successfully).
The screen saver does not interrupt the process.
The field named TAG has not caused an issue before and this particular app
has been in use for almost 5 years. (I inherited the database structure).
cheers,
Mark
"Marshall Rhinehart" <marc...@adelphia.net> wrote in message
news:ZNydnYuZ2vd...@adelphia.com...
Mark Chimes
I will send you an attachment later this afternoon.
Thanks,
Mark
"Geoff Schaller" <geoff...@softwarenospamobjectives.com.au> wrote in
message news:pBvdc.1358$ED....@news-server.bigpond.net.au...