What causes an Error 78 and/or sometimes "phantom" records in a browse?


#1

Here is a reproduction of my old PTSS report. @Mark_Sarson might be able to describe the situation he found today with phantom records due to the same issue?

Clarion 8 PTSS - http://problemtracker.softvelocity.com/clarion8/UpdtCustBugsview.php?ID1=39361
Clarion 9 PTSS - http://problemtracker.softvelocity.com/clarion9/UpdtCustBugsview.php?ID1=39361


Problem Reference: 39361
Date Received: 2012-05-30
Status: Opened for Review
Fixed in Build Number:
Product: Clarion8
Build No: 89285
Operating System:
Category ID: ABC Classes


Summary: Variables used with return value from Position() are not large enough

Description:

The ABC Browse template and classes have a String(1024) declared to hold the return value from Position(). There are circumstances where this is not large enough.

When the templates/classes subsequently try to use a truncated saved position in a call to Reset or Reget an Error 78 is thrown.

Steps to Reproduce:

This is occurring on an SQL based view with several joined tables.

It is currently triggered when used in conjunction with the SortHeader extension/class.

Changing the browse template and classes to have a larger string stops the Error 78 from occuring.

I have marked this as reproducible=always but it does depend on view structure and data withing the view so it is also not always easy to reproduce.

Only tested in Clarion6 but Clarion7-8 have the same template/class string sizes.

Reproducible: Always
Severity: Major
Visible to public: Yes
Example App: None submitted


#2

Our issue, which is caused by the same problem (Storage variables defined to store the POSITION(file.key) etc are not large enough @1024 characters.

The problem I had was with Browses that would have a column that is defined fairly large on the backend (In this case VARCHAR(512). Upon clicking the header to sort the browse in the order of that column, when I scrolled the scroll bar, we would see multiple rows with the same data.

This of course is a classic symptom of not using the pk filed in sort orders, however in our case we were using the primary field, so we could rule that out.

After searching the CLW’s, INC’s and TPx files I modified any local variables that were used to store position in the classes to ANY. There are also some fields in queues that needed modifying of their size.

Going through my diff’s these are the changes I made to correct this error.

###ABBrowse.clw
#####BrowseClass.ResetQueue PROCEDURE(BYTE RefreshMode)
HighlightedPosition from STRING(1024) to ANY

#####BrowseClass.UpdateViewRecord PROCEDURE
Pos from STRING(1024) to ANY

###ABFile.CLW
#####FileManager.UpdateServer PROCEDURE(BYTE HandleError)
HOLD from STRING(1024) to ANY

#####RelationManager.Delete PROCEDURE(BYTE Query)
Current:Position from STRING(1024) to ANY

###abvcrfrm.inc
VewPosition from String(1024) to STRING(10000)

###ABVCRFRM.CLW

#####FormVCRClass.CheckBorders
LastRecordPosition from STRING(1024) to ANY

#####FormVCRClass.Fetch
LastRecordPosition from STRING(1024) to ANY

###ABTblSyn.INC
DeletedRecordsQueue QUEUE,TYPE
RecordPosition STRING(10000)

###ABWindow.Inc
LastInsertedPosition from STRING(1024) to ANY

###ABBrowse.TPW

Change
INSERT(%MakeField, ‘ViewPosition’, ‘’, ‘STRING(1024)’,‘Entry’‘s view position’)
To
INSERT(%MakeField, ‘ViewPosition’, ‘’, ‘STRING(10000)’,‘Entry’‘s view position’)

###ABRELTRE.TPW
change occurs in two places
From
%[20]ValueConstruct STRING(1024) #<! Record POSITION in VIEW
To
%[20]ValueConstruct STRING(10000) #<! Record POSITION in VIEW

These are the changes I can find, put please post here if you find any more.


#3

Does ANY means Clarion type or just anything?


#4

I’m sure @Mark_Sarson means the ANY data type. It can have any length.


#5

Thank you for clarification :relaxed: :+1:


#6

That is correct Rick. Thanks for clarifying.


#7

I have a Browse / Form that from time to time when the user Clicks on the from OK it gets error 78.
Any way of inspect the ViewPosition Value?


#8

You could edit the template and put in something to log the value, at least while diagnosing it. Unless you can repeat the problem on demand, then step through with the debugger I suppose.