Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Parameterized view in a report
Message
De
19/08/1997 10:39:26
 
 
À
19/08/1997 06:52:34
Matt Mc Donnell
Mc Donnell Software Consulting
Boston, Massachusetts, États-Unis
Information générale
Forum:
Visual FoxPro
Catégorie:
Gestionnaire de rapports & Rapports
Divers
Thread ID:
00045394
Message ID:
00045526
Vues:
58
>>>>>>>How wuold I go about basing a report on a parameterized view? Is it possible without using a public variable? ie- can I pass the paramater by value to the report?
>>>>>>
>>>>>>It's actually local variable:
>>>>>>
>>>>>>***cmdRunreport click event
>>>>>>local nViewparameter
>>>>>>nViewparameter=....
>>>>>>Select view1
>>>>>>=requery()
>>>>>>Report Form ....
>>>>>
>>>>>Erik,
>>>>>
>>>>>Can I assume that you want this to be a 'standalone report' with the view in the report's DE? If so, what if you put code in the DE's Init to prompt the user for the parameter(s) and then add the view to the DE using the parameters you collected..
>>>>>
>>>>>HTH
>>>>
>>>>No can do. Tables in question use surrogate keys that the user would have no idea about.
>>>
>>>In that case, use Ed's idea with the Default DS
>>
>>I could use the default datasession on the report, but the form that it prints from uses a private datasession, and must stay that way, because the program allows the user to open multiple instances of the for... what I was hoping for was a way to pass the parameter to the report. I suppose that I could save my view with a different name and remove the parameter in the view itself, and then REPORT FORM for parameter = value. This would quickly make the number of my views explode, however, because I have a lot of forms that display the data from a view in which I want to put a print button to allow the user to print the data on the screen in a formatted report.
>
>OK Erik, here's my last shot. In the BeforeOpenTables event, issue a SET DATASESSION TO (_Screen.MyForm.DataSessionID). I guess that will mean that as long as the form is a member of _SCREEN, then you won't have to declare anything public. Don't put any tables in the report's data environment.
>
>NOW, you should be able to use Ed's idea.
>
>HTH.

Matt- that's a pretty creative idea, I didn't know you could do such a thing. I still foresee problems however with multiple instances of the form. If the name of the form is hardcoded into the report, than I would have to open the form with NAME to make sure that any instances get the right name, and this would generate an error once the second form is opened. If I rely on VFP to name the forms as they are opened it will give additional instances different names to avoid a name already in use, and the report would not recognize which form to set its datasession to. I really appreciate all of your ideas, Matt, they have really helped me to brainstorm. As for now though, I think I will have to go with the alternative view without its parameter. Thanks again.

Erik

Erik
Erik Moore
Clientelligence
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform