Reporting on data parsed from text (notes) field

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a standard field which I am going to be parsing using a regular
expression.
I'm going to pull out values from specific locations (such as date), and
filter on them. I will then have a number of independant data objects which
I want to inset into a report. Most likely my storage method until time of
reporting will be a dictionary.

My question is, what is the best or most efficent way to store the temporary
data so that it can be used in (passed into) a standard Access report?

As I iterate through my dictionary I need somewhere to put the data. While
I could use a temporary table, I'm trying to avoid this.

Thanks,

-David
 
DBG said:
I have a standard field which I am going to be parsing using a regular
expression.
I'm going to pull out values from specific locations (such as date), and
filter on them. I will then have a number of independant data objects which
I want to inset into a report. Most likely my storage method until time of
reporting will be a dictionary.

My question is, what is the best or most efficent way to store the temporary
data so that it can be used in (passed into) a standard Access report?

As I iterate through my dictionary I need somewhere to put the data. While
I could use a temporary table, I'm trying to avoid this.
Click to expand...


Tables are the fundamental storage method in Access.
Anything else, (possibly excepting an ADO disconnected
recordset), will have to be converted to a table anyway, so
why do the extra work of using a different mechanism and
then a conversion procedure?

While temporay tables are to be avoided, done right, they
can be quite effective. For some good ideas, see
http://www.granite.ab.ca/access/temptables.htm

OTOH, you can easily use VBA in the report to parse the
field and put parts of it in different report text boxes, so
a temp table may not be needed at all.
 
Tables are the fundamental storage method in Access.
Anything else, (possibly excepting an ADO disconnected
recordset), will have to be converted to a table anyway, so
why do the extra work of using a different mechanism and
then a conversion procedure?

While temporay tables are to be avoided, done right, they
can be quite effective. For some good ideas, see
http://www.granite.ab.ca/access/temptables.htm
Click to expand...

Thanks for the link.
OTOH, you can easily use VBA in the report to parse the
field and put parts of it in different report text boxes, so
a temp table may not be needed at all.
Click to expand...

This could probably work, I suppose I would need to pass the values from my
filter form to the report, I hadn't considered this before.

Thanks,
-David
 
Back
Top