Hi,

I’ve run into a perplexing situation with my office’s Paradox database, and I’m fishing for clues.

Several years back, we hired someone to develop a database to track membership on various committees. The developer used Paradox 5 and ObjectPAL to create forms for the database interface. Some years later, I inherited responsibility for maintaining the database, so I had to try to learn ObjectPAL. When we upgraded WordPerfect to version 8, I began using Paradox 8 with the database. As I recall, I ran into very few problems converting the existing forms to the newer version of Paradox.

Recently we upgraded to WordPerfect 12, which also gave us Paradox 11. Paradox 11 required me to redeliver all the forms using the newer version, and I was able to do this successfully. However, there is one form that now gives us an error intermittently, and I cannot determine what the problem is.

The form is used to generate a report of the membership for a given committee. On the form, the user selects three parameters from drop-down menus: committee name, begin date and end date. When we converted to Paradox 8, I modified some of the ObjectPal code on this form, but the code has remained the same since then, and we never encountered the error that now occurs intermittently. I’ve identified the line in the source code where the error occurs, if it occurs:

rSpecificCommRpt.txtYear.value = “Membership for ” + arRetVal[2].subStr(arRetVal[2].size() - 3,4)

where arRetVal[2] is the begin date (e.g., “9/1/2004”) and arRetVal[2].subStr(arRetVal[2].size() - 3,4) retains just the four-digit year (i.e., “2004”) so that rSpecificCommRpt.txtYear.value is “Membership for 2004”

[As an aside, the original line of ObjectPAL code from Paradox 5 was

rSpecificCommRpt.txtYear.value = “Membership for ” + arRetVal[2]

The modification using subStr was made so that the generated report would display “Membership for 2004” instead of “Membership for 9/1/2004”.]

The truly odd thing about this problem is that if I select a committee and dates of service, the report might be generated successfully once, twice, whatever. But moments later, I can use the exact same parameters, and instead of the report being generated, an error occurs:

“Unexpected: General Protection Violation.

Press ‘OK’, then save your documents and exit Paradox. If the problem persists: press ‘Abort’ to terminate Paradox.”

Making no changes either to the ObjectPal code or to the selected parameters can yield different outcomes, and I am completely mystified.

The operating system is Windows 2000 w/SP4, for what this may be worth.

Thanks for any comments or suggestions anyone might have.

Corrupted table?

Could it be that there is a memory leak, which surfaces after multiple runs of the code. This seems possible because it appears you are using a system variable in that code. You could explicitly release the variables after running the report which could ameliorate that.

Thanks for the suggestion about the possibility of a corrupted table. I re-created the tables that are used to generate the report (by querying the existing tables and using the resulting answer tables instead), but unfortunately this did not resolved the problem. I don't know whether this action is sufficient to eliminate the possibility of a corrupted table or not.

I'm intrigued by the notion of a memory leak. Can you explain how to explicitly "release" a variable?

So it turns out there are three places you can declare a variable.

withinthe method (after the method command) in which case the variable is initialized each time the method is run but is only accessible to the method.

outside the method but within the window (before the method command)

In an objects var declaration.

Where it is determines when it is released and where it is accessible.

If it is in an objects vars declaration then it is available to all object on the form all the time and is not reinitialized until the form is closed and reopened.

If it is outside the method then it is not released until the form is closed but is only available to the method.

If it is within the method it is initialized/released each time the method is run.

I will wager that this variable is in declared in the first or second ways and is thus piling up in the windows program (since it appears to be an array as well) . Could be this is causing an eventual GPF.

I would check that out.

Indeed, the variable arRetVal is an array. It is declared within the method:

method mouseClick(var eventInfo MouseEvent)

var

arRetVal Array[] String
atRetVal AnyType
frmSpecificCommRpt Form
rSpecificCommRpt Report
tcResults TCursor

endvar
. . .

so if my understanding is correct, arRetVal is initialized each time the report is run. But I'm thinking that your hypothesis is on the right track. I noticed in this method's code that the report variable rSpecificCommRpt is never explicitly closed (i.e., there is no line of code I could find that reads "rSpecificCommRpt.close"). I could try to add such a line in case is necessary to release arRetVal, but I really don't have a sense of whether this is the case.

I've found some information at http://web.comhem.se/~u82608896/para...ugs.htm#PX0615 that I believe describes the problem that I'm experiencing. According to the information on this site, a general protection violation error is known to occur in Paradox 11 (and v. 10 evidently) when using ObjectPAL to assign a value to a text object in a report. The line of code where my program (sometimes) fails attempts to do precisely this, i.e., rSpecificCommRpt.txtYear is a text object in the report, and the code is intended to assign a value to this text object.

Unfortunately, however, this error is labeled as a "current" bug, and no solutions or workarounds are identified.

Since you have played around with O-Pal, Have you considered using a calculated field in the report "Membership for " +Year(Begin Date)? If that text assignment is the actual problem that should get around it OK and nobody ever has to know. :-)

Thanks for the suggestion. I didn't know what you meant by calculated field, but this gave me another idea. I added the year fields (there are actually two of them - Begin Date and End Date) to the table from which the report is generated, and then in the report I replaced the text object that was causing the error with a field object. The year fields now come from the underlying table and are displayed using the field object.

(It was actually quite a bit more involved than what I've described, but this is the essence of the workaround.)

I really appreciate your comments and suggestions.

As far as a calculated field, on the field object you could define the field as calculated and then in the box for calculation you could use "Membership for "+Year(Begindate) and the field object would display "Membership for 2004". Very similar to what you've done as I had assumed that the begin date was already in the report table. Anyway glad I put you on to a workaround.

Lonnie