Hi, is it possible to prevent users from adding additional fields to filter on a report?
It needs some code, but its not too complex. Basically say you have a report based on MyTable and want the user to only be able to filter on three fields, MyCode, MyDate and MyBoolean. (Can be as many as you want of course). Then add the following code: Var: MyTableVar of MyTable; MyTableVar.COPY(Rec); MyTableVar.SETRANGE(MyCode); MyTableVar.SETRANGE(MyDate); MyTableVar.SETRANGE(MyBoolean); IF MyTableVar.Getfilters <> '' THEN ERROR('You are not permitted to add the Filter %1',MyTableVar.Getfilters); There are other ways of course, this is just one possible solution.
I see… Is there a way without doing any programming? Like preventing the user from inserting a new line on the report filter field screen?
I have not found a way. Sorry.
Another possibility is to put the desired filters on the RequestOptionsForm and disable the “normal” ReqFilterFields (by setting a key in the DataItemTableView). You can find an example of this in Report 25 “Account Schedule”. Some code is necessary, though.
There is no ‘no code’ way to disable filtering in certain fields. Once you expose one field to the user on a ragular dataitem tab, you expose them all. You can use Davids trick to make sure only certain fields have filter values. THat is probably the most readable way to do it too, and less development than putting certain fields on the request form.
Is there a way to reset the filter fields on reports when you run the report?
yes on predataitem, write reset.
But won’t that reset the filters you’ve set on the report? What I meant was when you run the report, the filter fields only displays the filters set on the ReqFilterFields property on the report. As if you recompiled the report and the user settings were reset.
Sorry, I’m afraid the standard answer to this is, that it can’t be done without recompiling the object or deleting the .zup file. I once wrote a piece of code that “zaps” an object runtime - i.e. clears the object in the same way as a recompilation does. I can’t seem to locate it now, though - but if you’re interested I’ll have a look in the archives 
YES! If you have the code handy it will help tremendously!
Hello again, After some digging I found it - so here goes… Create a function (in a Codeunit called Zap for instance): ZapObject(ObjectType : Option;ObjectNo : Integer) ZapFile := ‘C:\Zap.txt’; IF Object.GET(ObjectType, ‘’, ObjectNo) THEN BEGIN Object.CALCFIELDS(“BLOB-reference”); Object.“BLOB-reference”.EXPORT(ZapFile); Object.“BLOB-reference”.IMPORT(ZapFile); Object.MODIFY; END; (Object is a variable of type Record 2000000001 Object) The function exports the object and then reimports it, and thus, in effect zaps it, i.e. deletes all saved filtervalues etc. (just like a recompilation). If, for example, you want to “zap” a report you’d call the function from the OnPostReport() trigger: Zap.ZapObject(Object.Type::Report, REPORT::MyReport); Use it at your own risk - I’ll not be held responsible for any adverse consequences [8D]
Hehe, ye olde runtime object export/import function. [:D]
Brilliant!!!
quote:
Use it at your own risk - I’ll not be held responsible for any adverse consequences [8D]
Originally posted by Steffen Voel - 2005 Dec 13 : 19:50:49
Hi, this function works beautifully! I just noticed you put this at the end of the post. What kind of problems should I be expecting? Is it database crashing? Object crashing? Data erasing? ??