Why Can't Paradox Handle Filter Changes? 2

[SonOfTed]

I have managed to create some VERY good systems in Paradox with the exception of reports whose filters change from month to month.

1. Report objects run fine as long as filters do not change from month to month and are stored with the report file.

2. As soon as the user has to open the report in Design mode and change a simple text or date filter, all of a sudden the report bombs after generating a page or so.

Unexpected: General Protection Violation

Every time!

Then Paradox gets all screwed up and I have no choice but to restore the report from a backup since it is now corrupt.

WHY?

 

[SonOfTed]

Additional information:

I was finally able to get the report to print by adjusting the fields on the Design screen so that the page break changed.

Why should the screen preview and WHERE the page break occurs cause trouble? It was only a 2 page report... and not like the report generated was threatening the PC's memory or anything.

I don't like Version 11 very much. I was able to get some people who know almost nothing about computers to work very well with Paradox's user-friendly forms and reports, but since we went to 11 the reports bomb out on a regular basis.

Very frustrating for them.

 

[ACCESSDUMMY]

Hi,
I don't know why Paradox and filters don't agree, but I have learned to NOT use them in Paradox. We recently had to remove all filters from Paradox forms and reports due to problems when the program is shared by more than one user. It's like the filters get confused?? Our work-around was to simply query down the information that we were once filtering for and use the query answer tables for the forms and reports. It's more timely, but it works.
I hope this helps you.
Amy

 

[SonOfTed]

Thanks for the info.

I guess I don't plan to abandon filters altogether just yet. So far the following solutions have worked well for me:

1. Setting up a ONE row table with the row containing parameters that can be changed each month. The report object then references that row rather than filters.

2. Putting basic filters in the report and saving them. If the filter criteria doesn't change from month to month and the user just double-clicks the report object to run it, everything works okay for me. It's just when they have to open the object in design mode first and change dates and things in the filter window that things go wrong.

3. When working on a field with a calculation in it, just changing the formula directly and clicking okay causes a similar problem. To correct this I:

A. Cut the formula out of its area at the bottom of the define field window and uncheck the calculation box.

B. Click OK to reset the field. You know the field is reset correctly because the "LABEL" text reappears in the label portion (left side) of the field.

C. Paste the old formula into Word Perfect and make changes to it. Once it is okay, copy it and paste it back into the "Define Field" calculation area in Paradox. Click OK to apply the new formula to the field.

D. If the formula is correct the change will work and all you have to do is retype the text you want by replacing "LABEL" or (if you don't need it) delete the text entirely.

These things are working very well for me but as soon as my users have to open a report object in Design mode, unpredictable weirdness ensues.

I'm frustrated too because I checked into the possibility of executing a report from a button on a form. This works, but there is currently no way in Paradox I know of to pass filter criteria entered on the form to the report when running the report. That would also be a neat way to avoid having users open the report in Design mode.

The filter thing really bugs me, because all the Paradox documentation talks about how easy it is to just "filter" out the info you don't need. If it works so well on tables, how come it doesn't work as well on reports and forms. It sure used to on the older versions. I never had any problems with this before we went to Version 11.

* Deep breath & rant ends *

 

[bayBell]

Don’t store the filter with the report
base the report on the answer table
Run the report through a button on the form
I assume that your filter is on a date field. If that is true then
Instead of a filter use a Query
Create on your form, two undefined fields, “StartDate” & “EndDate”
“This is what I use for my monthly invoices, for my accountant.”
Create a button. Give it a name.

method pushButton(var eventInfo Event)
var
invQbe Query
rptInfo reportopenInfo
rptName Report
endVar
;//change the query using your table or tables
invQbe = Query
ANSWER: RIV:ANSWER.DB

WORKORD.DB | Invoice No | Customer No | Invoice Date |
| Check | _EG01 | Check >=~(StartDate), <=~(EndDate) |

WORKORD.DB | Total Taxable | Tax | Total | Non Taxable Sales |
| Check | Check | Check | Check |

CUSTOMER.DB | Customer No. | Last Name/Company |
| _EG01 | Check |

EndQuery

if invQbe.executeQbe() then
rptInfo.name = "monthinv" ;//use your report name here
ELSE
beep()
msgInfo("Can't Perform Report Query", errorShow())
return
endIf

if not rptName.open(rptInfo.name, winStyleMaximize + winStyleHScroll
+ winStyleVScroll) then
msgInfo("Can't Print Report", ErrorMessage())
endIf
endMethord

if there are other filter criteria, then create another button and undefined field. Code the button.

 

[SonOfTed]

bayBell said:

> Don’t store the filter with the report
> base the report on the answer table

That's one of the BETTER suggestions I've heard. I will keep this in mind when designing newer systems and enhancing old ones.

I have been hesitant to start using too many "buttons" and "ObjectPal" code because I have only limited experience with Paradox coding. When I try to put code in things I usually end up with more problems than the filters!!-)

Thanks for the suggestions!

 

[SonOfTed]

One of the employees I work with was running a Paradox report today and ran into an "Unexpected General Protection Error" when trying to print the report. It was only 16 pages in length.

The flaw appears to be in the Paradox Report Object, not necessarily its filters. Although the employee does change the filter criteria from month to month, the data comprising the report also changes (naturally) and I've noticed the page breaks also change from month to month.

Once again, the "old reliable" fix was to adjust the report design and change the page breaks, then resave the report object.

Simply by adjusting the bands a little upward or downward, the length of the report and the location of the page breaks changes.

It's an easy change and fixes the problem, folks.

I had such high hopes for Tony's "Local Share = True" suggestion. I have a test group of 5 PC work stations that use one Paradox system. All of them have this set to "True" rather than false. So far, the problem still looks like it's the report objects themselves.

 

[SonOfTed]

2-03-2006: Additional update on report problems.

Just to let everyone know, occasionally I still get "General Protection Violation" errors or other messages when running reports or modifying them in design mode. Another tip I have found to minimize this problem:

1. I used to use the "Report Expert" to specify a starting table and throw a few fields onto a new report to get me started.

2. Then I'd let the Expert generate a basic report (with a header, page number, date/time stamp, and other basic info) and I'd just modify it from there. Linking in other tables, etc.

3. I've found that if I don't use the Expert (and just start with a completely blank report) it may take me a bit longer to create a new report from a completely blank page but I HAVE had less problems... particularly with reports losing their "links" to assigned fields when opened in design mode.

4. I don't think this is a perfect solution, but I am no longer certain that the "Report Expert" is entirely trustworthy these days.