Hi,
I would like to use the TMSQuery.RecNo property for synchronizing with stringGrid-data but when used within the OnFilterRecord-event the RecNo returns unsuiteable data. In AfterScroll- and other events the .RecNo-data seems to be correctly assigned. Is there a way to have the right RecNo also in the FilterRecord-event?
best regards
Toni Santa
RecNo property in OnFilterRecord-event
-
AndreyZ
Hello,
The RecNo property is used to indicate the ordinal position of the active record in the recordset. During filtering this property is useless, because records are still being filtered, and it's impossible to determine the number of the current record.
Please describe in details the functionality you are trying to implement. Maybe we will be able to suggest you some solution.
The RecNo property is used to indicate the ordinal position of the active record in the recordset. During filtering this property is useless, because records are still being filtered, and it's impossible to determine the number of the current record.
Please describe in details the functionality you are trying to implement. Maybe we will be able to suggest you some solution.
hi Andrey,
Thank your for your prompt response. I will try to make a simple sample of what I'm trying to implement: A query returns a result where some records have same values in all fields and I load them into a stringgrid where in addition to the data one column contains the RecNo and one column a checkbox for selecting the record. Now the application should print only the selected records (or do other stuffs on selected records) so I would like to filter the behind dataset on selected columns to pass it to quickreport (fastreport or what else..). There I thought the simplest way would be to use the FilterRecord-event, take the msQuery.RecNo, look inside the grid if the row with given RecNo-column is selected and set the Accept-variable in according to this. Since the query could return more records with all fields with same value, there is no unique primary key. Assigning a guid or incremental virtual (calculated) field inside the query would slow down the loading of the data.
If you have some good and functional idea, your are welccome.
best regards
Toni
Thank your for your prompt response. I will try to make a simple sample of what I'm trying to implement: A query returns a result where some records have same values in all fields and I load them into a stringgrid where in addition to the data one column contains the RecNo and one column a checkbox for selecting the record. Now the application should print only the selected records (or do other stuffs on selected records) so I would like to filter the behind dataset on selected columns to pass it to quickreport (fastreport or what else..). There I thought the simplest way would be to use the FilterRecord-event, take the msQuery.RecNo, look inside the grid if the row with given RecNo-column is selected and set the Accept-variable in according to this. Since the query could return more records with all fields with same value, there is no unique primary key. Assigning a guid or incremental virtual (calculated) field inside the query would slow down the loading of the data.
If you have some good and functional idea, your are welccome.
best regards
Toni
-
AndreyZ
Maybe the following idea will be useful for you:
- load data to the TStringGrid component with one additional column for selecting records;
- after selection, copy selected data to the TVirtualTable component and pass it to your report.
This way you don't have to work with the RecNo property and perform comparison with it. All work is performed in the memory, and that's why it will be quite fast (at least for not huge queries).
- load data to the TStringGrid component with one additional column for selecting records;
- after selection, copy selected data to the TVirtualTable component and pass it to your report.
This way you don't have to work with the RecNo property and perform comparison with it. All work is performed in the memory, and that's why it will be quite fast (at least for not huge queries).