Página 1 de 1

AddDbf

Publicado: Lun Nov 17, 2014 5:38 pm
por nbatocanin
I have doubts about how works AddDbf. For example, I want to show only one row from the table:
oFr := FrReportManager():New()
USE Test NEW
SET FILTER TO RecNo() == 10
GO TOP
oFr:AddDbf ("Test", "Test->*")
// SET FILTER TO
oFr:DesignReport()
oFr:End()
This example works correctly. But, if you uncomment SET FILTER before calling the DesignReport, FRX show all Test table!
Is this normal behavior? I thought that AddDbf copy the table into memory?

AddDbf

Publicado: Lun Nov 17, 2014 6:37 pm
por ignacio
nbatocanin escribió el lun, 17 noviembre 2014 17:38I have doubts about how works AddDbf. For example, I want to show only one row from the table:
oFr := FrReportManager():New()
USE Test NEW
SET FILTER TO RecNo() == 10
GO TOP
oFr:AddDbf ("Test", "Test->*")
// SET FILTER TO
oFr:DesignReport()
oFr:End()
This example works correctly. But, if you uncomment SET FILTER before calling the DesignReport, FRX show all Test table!
Is this normal behavior? I thought that AddDbf copy the table into memory?
It is copied into memory but not on the AddDbf statement. But when the DesignReport method is called. Call TFastReport:PrepareReport() before setting set filter off.
Regards,

AddDbf

Publicado: Lun Nov 17, 2014 11:24 pm
por nbatocanin
Thanks!
Which is the preferred method for the selection of several records from the table? For example, I have a array of RecNo() and want to show this records from a large table?

AddDbf

Publicado: Mar Nov 18, 2014 11:49 am
por ignacio
nbatocanin escribió el lun, 17 noviembre 2014 23:24Thanks!
Which is the preferred method for the selection of several records from the table? For example, I have a array of RecNo() and want to show this records from a large table?
Use TFastReport:AddArray
Regards,

AddDbf

Publicado: Mar Nov 18, 2014 4:03 pm
por nbatocanin
Hmmmm, I was hoping that there is a more elegant way . AddArray can be used in simple table cases, but if there are multiple related tables, it is not an easy task. For example, I have a invoice-items table that is related to articles table. Currently I create a TMP table that keeps RecNo() of all invoice-items and then use AddDbf:

// Fill TMP with RecNo()
SELECT Items
SET RELATION TO i_art INTO Articles
SELECT Tmp
SET RELATION TO t_recno INTO Items
GO TOP
oItems := oFr:AddDbf ("Items", "Items->*")
oArticles := oFr:AddDbf ("Articles", "Articles->*")

AddDbf

Publicado: Mar Nov 18, 2014 5:19 pm
por ignacio
Dear Sir,
FRX can also use relations, both DBF related or FR related. Check our master-detail examples.
BTW, the way you filter the records is completely up to you.
Regards,

AddDbf

Publicado: Mar Nov 18, 2014 7:32 pm
por nbatocanin
ignacio wrote on Tue, 18 November 2014 17:19Dear Sir,
FRX can also use relations, both DBF related or FR related. Check our master-detail examples.

Yes, I've studied all the examples in detail and I use SetMaster constantly. My message is related to easy sending parts of the large tables in the FRX engine. I think that this can be improved on a FRX level, but AddArray will be enough.
By the way, I noticed a significant slow down when executed PrepareReport() compared to Spirin's version, even with very small amounts of data? Do you have any recommendations how to speed up?
Regards, NB

AddDbf

Publicado: Mié Nov 19, 2014 12:06 pm
por ignacio
nbatocanin escribió el mar, 18 noviembre 2014 19:32ignacio wrote on Tue, 18 November 2014 17:19Dear Sir,
FRX can also use relations, both DBF related or FR related. Check our master-detail examples.

Yes, I've studied all the examples in detail and I use SetMaster constantly. My message is related to easy sending parts of the large tables in the FRX engine. I think that this can be improved on a FRX level, but AddArray will be enough.
By the way, I noticed a significant slow down when executed PrepareReport() compared to Spirin's version, even with very small amounts of data? Do you have any recommendations how to speed up?
Regards, NB
Probably your problem is due the tremendous slowness of the SET FILTER command. Send a sample using an array and we will have a look at it.
Regards,

AddDbf

Publicado: Mié Nov 19, 2014 2:13 pm
por nbatocanin
I'll try to prepare a small example (I do not use a SET FILTER in this code).
Regards, NB

AddDbf

Publicado: Mié Nov 19, 2014 8:06 pm
por nbatocanin
I made a test for Spirin's and Xailer's version (in attachment). Each table has less than 100 records. I started a program on a shared network drive. Here are the results:
Spirin: 1.15 + 0.10 = 1.25 sec
FRX: 0.07 + 5.53 = 6.00 sec
First time is initialization, and the second is PrepareReport() call. If necessary, I can send all the DBF data and exe files.
Regards, NB


Attached files test.zipped (5.3 KB)Â

AddDbf

Publicado: Mié Nov 19, 2014 9:10 pm
por ignacio
nbatocanin escribió el mié, 19 noviembre 2014 20:06I made a test for Spirin's and Xailer's version (in attachment). Each table has less than 100 records. I started a program on a shared network drive. Here are the results:
Spirin: 1.15 + 0.10 = 1.25 sec
FRX: 0.07 + 5.53 = 6.00 sec
First time is initialization, and the second is PrepareReport() call. If necessary, I can send all the DBF data and exe files.
Regards, NB

Dear Sir,
FRX normally retrieves all the data on the PrepareReport() statement, Spirin does not. it retrieves on a demand basis. This means, that only when you change the page on a preview the data is retrieved. This can be changed with the TFrDataset:lLoadOnDemand property.
I suggest you made the test also exporting to PDF, for example.
BTW, you code can be easily enhanced this way (since you are using relations):
oProI := oFr:AddDbf ("Proizlaz", {"Proizlaz->*","Artikli->*"} )
Regards,

AddDbf

Publicado: Mié Nov 19, 2014 11:28 pm
por nbatocanin
[quote title=ignacio wrote on Wed, 19 November 2014 21:10]nbatocanin escribió el mié, 19 noviembre 2014 20:06
FRX normally retrieves all the data on the PrepareReport() statement, Spirin does not. it retrieves on a demand basis. This means, that only when you change the page on a preview the data is retrieved. This can be changed with the TFrDataset:lLoadOnDemand property.
I suggest you made the test also exporting to PDF, for example.
Unfortunately, there is no change: Spirin 1.25, FRX 5.60.
Quote:BTW, you code can be easily enhanced this way (since you are using relations):
oProI := oFr:AddDbf ("Proizlaz", {"Proizlaz->*","Artikli->*"} )

I am aware that, but I need two separate tables with own names, for compatibility reasons. I was planning to use AddArray to manually collect data to memory and probably speed up the system, but I have a problem with empty tables :((
Regards,
Nenad Batocanin
Wings

AddDbf

Publicado: Jue Nov 20, 2014 10:02 am
por ignacio
Cita:Unfortunately, there is no change: Spirin 1.25, FRX 5.60.
As I can see on your code you are using up to 7 DBF files passing absolutely all its fields and records. Even worst, you are creating relations you never use in the report. They are completely useless and even consume time because skip operations on master tables affect related tables.
Sergey software consumes data on a demand basis and does not create memory datasets as we do. For that reason there is no penalty on passing all the records and all the fields of those records. FRX creates memory datasets, so is important you only send THE DATA YOU NEED TO SEND, not your complete database. So:
1) Select only the fields you need
2) If your are using DBFs creates relations at Harbour level and then pass the master table with all ist relations in a single dataset
USE CIENTS NEW
USE INVOICES NEW
SET RELATION TO Invoices->Client INTO CLIENTS
oReport:AddDbf( "Invoices", { "Invoices->Id", "Clients->Name" }

BTW, please send the data files and I do some tests.
Cita:I am aware that, but I need two separate tables with own names, for compatibility reasons. I was planning to use AddArray to manually collect data to memory and probably speed up the system, but I have a problem with empty tables (
You can use expressions like this Client->Id AS ClientNumber
When relations in related tables are not solved the record pointer goes to EOF. There should be no problem if you use relations.
Regards,

AddDbf

Publicado: Jue Nov 20, 2014 3:55 pm
por nbatocanin
ignacio wrote on Thu, 20 November 2014 10:02
As I can see on your code you are using up to 7 DBF files passing absolutely all its fields and records. Even worst, you are creating relations you never use in the report. They are completely useless and even consume time because skip operations on master tables affect related tables.
This example is only a simplified version of what I need. I think that the program loads only the necessary records, on which table you mean? I think that test loads only a few records, in practice, these tables can be very large (> 1 million records). All relations are used too because the user can select multiple documents (in test here shown only one). All fields are also necessary.
Quote:BTW, please send the data files and I do some tests.
All data + exe is on link:
https://drive.google.com/file/d/0BwEGIJ ... k0wR1R4Qkk /view?usp=sharing
We have more than 1.000 users with 3-4.000 scripts, it is important to minimize the changes required to the FR3 scripts. It seems to us the best chance to use AddArray, but here we need your help on empty tables - how to add them on report?
Thank you for your help.
Regards, NB

AddDbf

Publicado: Jue Nov 20, 2014 6:42 pm
por ignacio
We have just upload a new version of FRX that supports empty arrays. You can donwload it from:
http://www.xailer.com/download?en&file=103
Regards,

AddDbf

Publicado: Jue Nov 20, 2014 7:07 pm
por nbatocanin
Thank you very much!!
Regards, NB