Report with no Data Environment 1

[SitesMasstec]

Hello colleagues!

Is it possible to create a report with no Data Environment?

That is, I am running a form, and this form has lots of variables read from 2 files.
Each field in a file, for example, the field NOMAGENT is stored in the memory variable YNOMAGENT, and then displayed in the form with the command in the Init procedure:

thisform.txtNOMAGENT.Value=YNOMAGENT

So, it is Ok for displaying hundreds of data fields in the form.

Now I have a print button in the form, and I want to create a Report to display the fields from the form. Is it possible to create a report to display just memory variables?

Thank you.

 

[igorsandler]

As long as those variables are public or global and the report has to be set with default data session. It's a bit weird, quite frankly. I don't see why you can't create a cursor at least with the fields selected on the form but without more details it's hard to day

 

[SitesMasstec]

Ok, Igor, but is it possible to create a Cursor to store three hundred memory variables? It seems that a Cursor has the same limit as a table, that is, 255 fields.

 

[ggreen61]

The variables do not have to be Public/Global. I do not use global variables at all. I do have memory variables referenced in reports. In the form method that will call the report, create the variables as LOCAL variables and they will be in scope when the report is run. You cannot reference in a report a form control such as a textbox; this being said, it might be possible to use _SCREEN.ActiveForm.txtMyTextBox.Value (I have not tried this and would not recommend doing this...)

 

[Joe Crescenzi]

You can definitely create a report doesn't reference any fields in a table, but the report generator expects to be run from the selected table or cursor so it knows where to start and end.

That said, there is no rule that any of the content on the page has to exist as a field/column in the selected cursor.

I have several reports that do exactly that. My customers wanted a way to print a number of "blank" sales tickets that could be filled in by hand whenever the printer or the system was unavailable. I originally asked them to just create something in Microsoft Word, but it would look too different from the real tickets, so I created a form that had nothing from the cursor, and lots of placeholders and underscores to fill in the details.

As I mentioned, the challenge was that the report generator knows where to start and end based on the position in SOMETHING and not be at the End Of File. So, I could literally use any table or a temporary cursor and run the report.

The trick is that if you want it to be exactly one page, you just need one row in your table or cursor so it stops after the 1st page or you need a filter that ensures it stops after one page. So you could select top 1 AnyFieldName from AnyTableName into cursor AnyCursorName, then when you use Report Form MyReport it will generate exactly one page, and yes, that page doesn't need anything from the cursor you created. As a bonus, if you want multiple copies, you can just put exactly that number of rows into your cursor.

 

[Scott24x7]

Sitesmasstec,
This is why we advised you not to do it this way previously. It's knock on problems as well.
If you normalized your data and tables, none of this would be an issue for you.

 

[Chris Miller]

I agree with Scott, and it's not only data normalization.

SitesMasstec, you're so deep and stuck in wrong software architecture that you have problems nobody else has. And that should make you change your ways, but you're not. I set you as ignored member with limited success, as this thread comes to my attention anyway, due to answers of others (I see this thread in my summary of forum activity since Greg answered, not just now that Scott adds his opinion).

I do not only second Scott, I have the opinion when someone obviously is on a totally wrong path that should be pointed out. Though I have that strong opinion I even agree since you're so far off from knowing how to do something that of course you need and should get help.


But this is not the case of inabilities of a baby that of course is relient on its parents. Let me point out (once more) you already know the answer and you just should look into answers you already had, before starting a new thread: https://www.tek-tips.com/threads/does-a-report-use-the-available-cursor.1830624/#post-7574745.

I still had a post after that, but the principle a report is driven by a workarea has already been teached to you and you stated that you understood that. If I dig, I guess I also find older threads that teached the same. Build up a knowledge base by bookmarking posts from which you learned. Use the forum search and your profile bookmarks to revisit something.

 

[tomk3]

We had problems using thisform. in a report. You may iterate through the controls collection of the form and add the values (and name or description from TAG) as propertys to a "printobject" which you can release on close of form. You may put it in title band and have a dummy cursor with one record (see above).

Anyway this is technically possible. I would recommend to think of better data organization

 

[EinTerraner]

Otherways You also can create a dataobject like

PUBLIC O_RepData
O_RepData = = CREATEOBJECT("empty")
ADDPROPERTY(O_RepData,"YourLabel_1",<yourvalue_1>)
....
ADDPROPERTY(O_RepData,"YourLabel_n",<yourvalue_n>)

Within the report >ou can access the data like any cursor- or tablefields (O_RepData.YourLabel_n)
and use a dummycursor mentioned above with one record

 

[igorsandler]

Ok, Igor, but is it possible to create a Cursor to store three hundred memory variables? It seems that a Cursor has the same limit as a table, that is, 255 fields.

Well, you have very valid responses from other users and I completely agree with them about this very strange request. Report with 300 fields on one page? That would be pretty hard to implement. But if you still want to do it, the suggestion to create a bogus cursor with a number of records for the number of pages you want and using those variables(I am not sure about locals but I am not saying that wouldn't work, I have never tried that) should work. Another suggestion to normalize the database is also valid, I just don't know your situation and software, if you had inherited it or design it. Regardless to re-write it would take some time, I would imagine

 

[Chris Miller]

You could even have thousands of fields, there's no limit once you relate multiple tables and sacrifice one field of each for a relation, you can relate N tables for N*254 fields. Besides normalized data allows you to use mor than one workrea, more than one record per page, etc. I already pointed out the general error about your general design in previous threads, no need to get into details. You also already were teached that this relation principle can extend the number of fields available at the same time, in a manner that SKIP in the main table also skips to the next record of related tables. You forget everything you learned.

 

[SitesMasstec]

Well, I created the report from zero.

The report has data from 2 table (table 1: one filtered record, table 2: till 5 filtered records). So I can have more than three hundred fields in the report.

Regarding your answers here, I can take the filtered data from original tables! It may not even be necessary to create Cursor, as I do for the Form.

Well, indeed it was my erlier idea, but I do not like to run a report from original tables, so I took the variables from the Form, which displays all the filtered data from the original tables.

Thank you all for the advices.

 

[ggreen61]

To everyone's point that you have to have a table/cursor that drives the page output. Using variables would cause every page printed to have the same value -- no point to print more than one page.

If each page is supposed to have different values, you could create two cursors that contain 150 fields each with a key field. The key field has to be the same between the two tables so that you can join one table with the other table. Now you can reference the full field list in the report. The two tables (cursors) must have an index on the key field. Set the parent table to the desired output order; set the child table to the key field order. If the key field name is 'keyfield', you would have the following:

SELECT c_child
INDEX ON keyfield TAG keyfield
SET ORDER TO TAG keyfield

SELECT c_parent
SET RELATION TO c_parent.keyfield INTO c_child ADDITIVE

REPORT myreport.frx TO PRINTER

 

[SitesMasstec]

Just to clarify:
In the Form, Init, I have this code:

*   Dados do Passageiro X
    FOR X= 1 TO 5
        strX=STR(X,1)
    
        frase="thisform.Pageframe1.Page" + strX + ".paxmarit.txtTKT.Value"
        &frase= YTICKET(X) 
    
        frase="thisform.Pageframe1.Page" + strX + ".paxmarit.txtNomePax.Value"
        &frase= YNOMEPAX(X)

* ...  plus lots of similar commands
NEXT X

The above variables (the fields TICKET, NOMEPAX, and many, many others) are read from 2 tables and stored in variables YTICKET(X), YNOMEPAX(X), etc

The Form is fine, it displays data from the 2 tables.

I would like to use these already available variables in a Report, just in case the user wants to print its contents.

I do not understand why it is not advisible to run a report with variables only. Anyway, I will stick to your advices and try to create a cursor (or a temporary file) with all the data for the report.

Thank you.

 

[Chris Miller]

I do not understand why it is not advisible to run a report with variables only.

It's also not advisable to do this with a form, but for a report you've been told multiple times even in this thread and in the post I linked to - a report does only run at all with at least one record of one table. Data is driving the report, the detail band of a report prints once for each record, with zero records it prints zero times, which means it prints not at all.

That's how report worked always, this is the case since many decades. You just do a lot of work for nothing as both reports and form controls can be data driven from tables and cursors, there has been no need for transporting data from DBF into variables since you have controlsources and report field expressions, You don't scatter and gather anymore, since the 90ies, at least.

 

[SitesMasstec]

I want to thank you all my colleagues for your valuable help, so I am accomplishing my task: