Printing records being filtered

[Generalsndy]

hello!

can anybody help me with this.

this code I used is to filter records:

SET FILTER TO sem = ALLTRIM(PROPER(thisform.cmb_sem.Value)) AND yr = ALLTRIM(PROPER(thisform.cmb_yr.Value)) AND (major="GENERAL" OR major= ALLTRIM(thisform.txtmajor.Value)) 
	GOTO top
	thisform.con_auto.grdSubject_table.Refresh

i added the code below before the condition but it prints nothing at all.
REPORT FORM C:\folder\Reports\sample.frx PREVIEW FOR sem = ALLTRIM(PROPER(thisform.cmb_sem.Value))...

 

[Scott24x7]

Do you know you have records that match your condition?
i.e. set the same conditions on the table you print from and see if there is an issue with your filter condition. Beware ALLTRIM functions, that could be where your issue is, as well as your AND/OR conditioning may be filtering all results out, so you're just getting what you are asking for.

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Generalsndy]

yes sir scott..i have already checked that..
i already tried one condition but it always shows nothing.

 

[Scott24x7]

Ok, so you are showing PREVIEW. Have you tried an actual print as well?
Also, clear all the print drivers from the .FRX


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

So you are setting a filter on the underlying table, but you are also filtering the records within the report (by means of the FOR clause in REPORT FORM). That doesn't make sense. Use one or the other method of filtering, but not both. The reason is that, if the conditions are not identical, one of the conditons might be excluding all the records from the other one, with the result that there are no records in the report.

I suggest you try removing the SET FILTER, and see if that gives the result you want. Then restore the SET FILTER, but remove the FOR clause.

Better still, remove both of them. Use SQL SELECT to get the records you want into a cursor, and then run the report against the cursor. That way, you will see exactly what data you are working with.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

If you set FILTER you set the expressions 1:1, you don't set the values the control.values have at the time of setting the filter.

THISFORM is only valid in the scope of a form. As you don't see erorrs that may not be the core problem, but it's a bad choice to use filters depending on the form scope, as the filter conditions scope is the workarea, not the form. That means the moment you activate another form and you locate or skip or anyway move in the table, the filter expression will error by not finding a cmb_sem control, for example. In shjort, any filter expression should only look at it's tables fields and otherwise have constants, string literals. To make this dynamic you might use public vars (bad idea, though works) or compose the full filter condition in a way you can use macro substitution.

In detail you make me wonder why a yr (I assume a year) would be equal to a string, a string you create with PROPER() with each first letter capitalized and others not, as obviously a year even as string would have no capitalisation and of course it's a number, not a string. But that's just a detail I may misunderstand the meaning of the field.

Bye, Olaf.

 

[Tore Bleken]

You should NEVER run a report from a table! Instead you SQL Select into a cursor, and run the report from the cursor.

 

[Dan Freeman]

You should NEVER run a report from a table!

Tore, you should NEVER say NEVER.

There are times when running a report from a table is exactly the right thing to do, particularly since the report form command accepts a scope.

Everything has a proper place and a proper time.

 

[Mike Lewis]

You should NEVER run a report from a table!

I agree with Dan. I don't see any reason for a blanket injunction against running reports from a table.

That said, in this particular case I would favour using SQL SELECT to generate a cursor, for the reasons I stated earlier.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Tore Bleken]

When I write NEVER I mean NEVER. The only exception I can think of, is in a single user environment. I never code for single user environment.

And to be honest, can you tell me one good reason NOT to run your reports from a cursor? Especially when more than one table is involved you create a single cursor with the fields and data you need. If you need some calculations, you do it on the cursor. If you want to see the actual raw data before the report is run, you Browse the cursor. I can count a zillion advantages and not a single disadvantage.

If you don't have a scope, the cursor will actually be the table, unless you add Nofilter or Readwrite. So what's the harm?

 

[Olaf Doschke]

The discussion drifts from the core problem. I think you really need to think about the validity of your filter expression and check, if it filters, as you think.

Start small, eg just with one filter condition.

Browse the table and look at a sem value. Pick it in cmb_sem and see what ALLTRIM(PROPER(thisform.cmb_sem.Value)) is.
To see that, you may set a breakpoint before the REPORT FORM and put that expression in the watchwindow or ? ALLTRIM(PROPER(thisform.cmb_sem.Value)) in the command window, or display it in a messagebox.
Do you really find this in the sem field?

If the items in cmb_sem actually come from the sem field of that same table, there is no reason to apply ALLTRIM() and PROPER() to a picked value, as that will have the same length and capitalisation as the sem values in the table, for example. The filter rather fails to pick the record you picked, as Alltrim(Proper(sem)) may differ from sem, eg Alltrim(Proper("MATH 101 ")) is "Math 101" and "MATH 101 " doesn't equal "Math 101". On the other hand Alltrim(Proper("Math 101 ") is "Math 101" so if sem values are in PROPER() capitalisation, that works. We don't know what items are available in the cmb_sem combobox, we don't know your data, therefore we can only guess many things and can't see a failure in your filter condition, as you think we might. Code and data always play together and code may not be wrong with the right data and vice versa.

Bye, Olaf.

 

[Dan Olsson]

tbleken: There are many advantages of a cursor, BUT if youre scope is one whole table why should I take the extra time to select it into a cursor?

 

[Mike Lewis]

I hesitate to continue this discussion (table vs. cursor for a report) because it is distracting attention from the main issue. I'll only add that I would personlly use a cursor in this situation, but there are many other cases where (as Dr D. points out), there is no good reason to take the extra time to select into a cursor.

General Sandy, I suggest you focus on the main problem, which is your overlapping filters. Do as I suggested earlier, and remove either the SET FILTER or the FOR clause, and see if that solves the problem. In any case, if the conditions are identical, using both types of filter is unnecesary and will only confuse the issue.

If that doesn't get you anywhere, do as Olaf suggested. Start with a single element of the condition, such as your test on cmb_sem's value, and build up from there.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Tore Bleken]

Actually using a cursor instead of a table, will in deed solve this problem, or make the solution more obvious. And that's why I live by the rule I mentioned. Instead of wondering what the heck is going on, like is it something wrong with my report, you can simply browse the cursor.