Process not working on laptop

[cmd]

Hi all,
I wanted to rule out other possibilities before suggesting a memory
upgrade for a user who owns a Dell Inspiron 6000 laptop with 512 MB of
ram.

I have a report based on a parameters query. The query selects billing
records for a specified date range and for a specified staff person (as
selected on a form). The underlying table for the query/report consists
of individual billing records with an Autonumber PK ("SrvID"). The
report advances a page after each SrvID. The printer is a networked
Xerox WorkCentre.

The date of the service is printed twice on the report -- once at the
top next to the service-type (counseling, therapy, etc.) and once at
the bottom of the report next to the signature line. This is simply the
same field from the query being printed in two separate areas of the
report.

The result is maybe 60 or 70 individual Progress Notes for a particular
staff person can be printed as a batch, rather than having to go
through the print process 60 or 70 times.

This procedure works without any problems on all the desktop computers.
It also works fine on certain laptops, including an older Acer
Travelmate which has only 128 MB of ram.

The specific problem that it is occuring on the Dell is that the date
at the bottom of the page does not always match the date at the top of
the page. For a "batch" spanning one calendar day, these two "dates"
consistently match -- as they should, since it's simply the same field
from the underlying query being printed in two separate areas of the
report. When the "batch" printed by the Dell spans multiple calendar
days, however, the results are quite inconsistent. Sometimes the two
"dates" match, but about 3/4 of the time the date by the signature line
at the bottom of the page does not match the date at the top of the
page. Sometimes it's a day or so earlier than the date at the top,
sometimes it's a day or so later than the one at the top. This type of
error can occur even when there's only 5 or 6 total Notes to be
printed. That is, the query doesn't have to produce a large number of
records for this error to occur. If the Progress Notes (or any other
reports) are printed "manually", that is, one-at-a-time by the Dell
laptop, there is no problem.

My question is, does anyone think that 512 MB of ram on the Dell
Inspiron 6000, with the wide screen etc., could simply be insufficient
to run this process accurately and consistently? The database
References all seem fine, and there's no indication of any other
problems running the database on this laptop.

Thanks for any insight or suggestions.
Mark

[David W. Fenton]

cm*@mountain.net wrote in
news:11*********************@i3g2000cwc.googlegrou ps.com:

My question is, does anyone think that 512 MB of ram on the Dell
Inspiron 6000, with the wide screen etc., could simply be
insufficient to run this process accurately and consistently? The
database References all seem fine, and there's no indication of
any other problems running the database on this laptop.

I would check on the laptop:

1. printer drivers.

2. Windows service pack.

3. Access version.

4. Jet version.

And see how those compare to the working computers.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[cmd]

Thank you, David
I removed and then reinstalled the printer driver yesterday. Everything
else printed from that laptop seems to print fine. We're running Access
2002 (FE: 2002, BE: 97 on a file server). The jet version is 4.0.8618.0
-- if msjet40.dll is what I'm looking for. The only thing I haven't
checked on is the Windows service pack. I'll do that when the person
brings in their laptop the next time and then post back.
Mark

David W. Fenton wrote:

cm*@mountain.net wrote in
news:11*********************@i3g2000cwc.googlegrou ps.com:

My question is, does anyone think that 512 MB of ram on the Dell
Inspiron 6000, with the wide screen etc., could simply be
insufficient to run this process accurately and consistently? The
database References all seem fine, and there's no indication of
any other problems running the database on this laptop.

I would check on the laptop:

1. printer drivers.

2. Windows service pack.

3. Access version.

4. Jet version.

And see how those compare to the working computers.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[cmd]

Thank you, David
I removed and then reinstalled the printer driver yesterday. Everything
else printed from that laptop seems to print fine. We're running Access
2002 (FE: 2002, BE: 97 on a file server). The jet version is 4.0.8618.0
-- if msjet40.dll is what I'm looking for. The only thing I haven't
checked on is the Windows service pack. I'll do that when the person
brings in their laptop the next time and then post back.
Mark

David W. Fenton wrote:

cm*@mountain.net wrote in
news:11*********************@i3g2000cwc.googlegrou ps.com:

My question is, does anyone think that 512 MB of ram on the Dell
Inspiron 6000, with the wide screen etc., could simply be
insufficient to run this process accurately and consistently? The
database References all seem fine, and there's no indication of
any other problems running the database on this laptop.

I would check on the laptop:

1. printer drivers.

2. Windows service pack.

3. Access version.

4. Jet version.

And see how those compare to the working computers.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[cmd]

David,
All the items you mentioned are the same on the desktops, laptops, and
this particular laptop that is having the problem.
Mark

cm*@mountain.net wrote:

Thank you, David
I removed and then reinstalled the printer driver yesterday. Everything
else printed from that laptop seems to print fine. We're running Access
2002 (FE: 2002, BE: 97 on a file server). The jet version is 4.0.8618.0
-- if msjet40.dll is what I'm looking for. The only thing I haven't
checked on is the Windows service pack. I'll do that when the person
brings in their laptop the next time and then post back.
Mark

David W. Fenton wrote:

cm*@mountain.net wrote in
news:11*********************@i3g2000cwc.googlegrou ps.com:

My question is, does anyone think that 512 MB of ram on the Dell
Inspiron 6000, with the wide screen etc., could simply be
insufficient to run this process accurately and consistently? The
database References all seem fine, and there's no indication of
any other problems running the database on this laptop.

I would check on the laptop:

1. printer drivers.

2. Windows service pack.

3. Access version.

4. Jet version.

And see how those compare to the working computers.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

cm*@mountain.net wrote in
news:11**********************@c28g2000cwb.googlegr oups.com:

All the items you mentioned are the same on the desktops, laptops,
and this particular laptop that is having the problem.

Well, *something* is different. I just don't see how RAM could be
the issue at all.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[cmd]

I agree. However, I'm starting to wonder if it might not be a network
hardware problem. The laptops plug into our network on payroll day, at
which time the staff person prints out their progress notes. Our DSL
provider switched our hardware this past summer, exchanging our router
for one of theirs. It seems that the problem may have begun after that
switch, but I'm not entirely certain of the timing. Could it be that
this particular report is just complicated enough that it can't be
handled properly by the network hardware -- or, at least on the
particular IP addresses serviced by the router for these laptops? (If
you're thinking: "well, that's just stupid!", I'll not take offense).

Anyhow, I just finished typing a lengthy post before reading your
response. I'll paste it here to see if that helps. Sorry for the length
and the vagueness of the problem.
....

I think I've figured out *what's* happening, but not *why* it's
happening... nor why it's happening on some laptops that on payroll
days get plugged into our network, but not on any of our desktop
machines. All the machines, including the laptops, are running the same
versions of Access, the same printer driver, etc. Perhaps it's an
interaction of weaknesses -- weakness in terms of the design of my
report, plus weakness in terms of network hardware (our DSL provider
recently replaced our router with one of theirs). Again, the report
works fine on our desktop computers, and the laptops are not showing
any errors on any other reports.

The report in question is based on a query which returns records from a
table of "progress notes".
The report advances a page after each progress note. A single progress
note could span more than one page. The progress notes table (progress
notes in our agency are called "Dap Notes") has the following
structure:

DapID -- autonumber, primary key (to distinguish each progress note)
LastName -- last name of the client
FirstName -- first name of the client
SrvDate -- date/time field -- short date (date of service)
SrvCode -- identifies the type of service
StartTime -- date/time field -- medium time (start time for that
particular service)
StopTime -- date/time field -- medium time (stop time for that
particular service)
.... other fields (location of service, staff provider, memo fields,
etc.)

I want the progress notes to be printed as a batch and to be grouped
alphabetically by client's last name and first name, with the most
recent date of service for that client on top, and with the most recent
time of service for that date on top. (A client could have multiple
services provided on a single date). ). Progress notes are rarely
written by staff in the order by which the service was provided; thus
the order of DapID's rarely matches the ordering of the progress notes
in terms of how we want those notes to be printed

The Ordering and Grouping option on the report consists of:

LastName -- ascending
FirstName -- ascending
SrvDate -- descending
StartTime -- descending
DapID -- ascending -- DapID has Group Header: Yes, Group Footer: Yes --
Force New Page After Section

SrvDate is printed in the Page Header (which also contains the client
name, type of service, etc.), as well as in the Page Footer -- next to
the staff's signature line.

The sections of the report are:

Report Header (empty)
Page Header (client name, type of service, date of service, etc.)
DapID Header (visible: no)
Detail (memo fields)
DapID Footer (visible: no; force new page: after section)
Page Footer (name of staff, signature line, date of service)
Report Header (empty)

The notes are being printed in the correct order. The error that seems
to be occurring on some of the laptops is that SrvDate (date of
service) is frequently being misprinted in the Page Footer. Instead of
matching SrvDate in the Page Header, it seems to match the SrvDate of
the next progress note that gets printed.

For example:

First note in printed output--
SrvDate in Page Header: 9/5/06
SrvDate in Page Footer (signature line): 9/7/06

Second note --
SrvDate in Page Header: 9/7/06
SrvDate in Page Footer: 9/10/06

Third note --
SrvDate in Page Header: 9/10/06
SrvDate in Page Footer: 9/10/06

Fourth note --
SrvDate in Page Header: 9/10/06
SrvDate in Page Footer: 9/15/06

.... again, this error does not occur on the desktop computers.

Could it be that the problem has something to do with the Ordering and
Grouping of DapID and the fact that a sorting order must be specified
(ascending or descending), even though this field is only being used to
advance a page after each progress note? (I could add/print this field
in the Page Header and Page Footer to see if that's what's happening on
the laptops).

I guess I could order the notes in a query (based on client, date, and
time of service) and send them to a temp table with a new autonumber
field, and then base the report (and ordering of the printed progress
notes) on this temp table -- ordered and grouped by this new autonumber
field.

I'm hoping you can see an obvious flaw in my design, or at least a way
to simplify it so that it's easier for the network to handle -- if it's
a question of resources and overloading the network and/or laptops.

Thanks,
Mark

David W. Fenton wrote:

cm*@mountain.net wrote in
news:11**********************@c28g2000cwb.googlegr oups.com:

All the items you mentioned are the same on the desktops, laptops,
and this particular laptop that is having the problem.

Well, *something* is different. I just don't see how RAM could be
the issue at all.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

cm*@mountain.net wrote in
news:11**********************@i3g2000cwc.googlegro ups.com:

The sections of the report are:

Report Header (empty)
Page Header (client name, type of service, date of service, etc.)
DapID Header (visible: no)
Detail (memo fields)
DapID Footer (visible: no; force new page: after section)
Page Footer (name of staff, signature line, date of service)
Report Header (empty)

The notes are being printed in the correct order. The error that
seems to be occurring on some of the laptops is that SrvDate (date
of service) is frequently being misprinted in the Page Footer.
Instead of matching SrvDate in the Page Header, it seems to match
the SrvDate of the next progress note that gets printed.

For example:

First note in printed output--
SrvDate in Page Header: 9/5/06
SrvDate in Page Footer (signature line): 9/7/06

Second note --
SrvDate in Page Header: 9/7/06
SrvDate in Page Footer: 9/10/06

Third note --
SrvDate in Page Header: 9/10/06
SrvDate in Page Footer: 9/10/06

Fourth note --
SrvDate in Page Header: 9/10/06
SrvDate in Page Footer: 9/15/06

... again, this error does not occur on the desktop computers.

I'm not sure I followed all of the above, but it seems me that the
SrvDate that will be printed will be the one drawn from the first
record printed in the detail of the start of the group, or of the
group repeat at the start of the next page.

That's the way it *ought* to work.

If I understand correctly, that would mean that the only PC printing
correctly is the *laptop*, which is just the same problem turned on
its head.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[cmd]

Yup, I must have lost you there ... sorry about that. Either that, or
I'm just so lost that I can't see that what you wrote is correct
(entirely possible).

Anyhow, each record in the underlying query is a Progress Note. Each
record contains a primary key (DapID), a date of service (SrvDate), the
type of service, a start and stop time, the client's name, and a
couple of memo fields. The memo fields are what comprise the Detail
section.

I tried looping through the query records, printing a separate *report*
on each record, but I thought that that was even more
resource-intensive -- opening and printing the report 60-70 times.
Also, that method produced a different problem -- the notes did not
consistently come out in the right order on the laptops, so the staff
person had to manually resort them.

This current report is grouped on, and therefore "breaks" (page
advances) after each DapID. This allows a single Progress Note (a
single DapID) to span multiple pages -- with the same identifying info
at the top of each page, plus the same signature-line and date at the
bottom of the page -- as well as going to a new page as a new DapID
comes up. I was thinking that there was only one Detail for the Detail
section for each DapID.

The date of service (SrvDate) is simply being printed in two places on
the page -- at the top in the Page Header section, and at the bottom in
the Page Footer section.

Hope this helps, David
Thanks,
Mark
David W. Fenton wrote:

cm*@mountain.net wrote in
news:11**********************@i3g2000cwc.googlegro ups.com:

The sections of the report are:

Report Header (empty)
Page Header (client name, type of service, date of service, etc.)
DapID Header (visible: no)
Detail (memo fields)
DapID Footer (visible: no; force new page: after section)
Page Footer (name of staff, signature line, date of service)
Report Header (empty)

The notes are being printed in the correct order. The error that
seems to be occurring on some of the laptops is that SrvDate (date
of service) is frequently being misprinted in the Page Footer.
Instead of matching SrvDate in the Page Header, it seems to match
the SrvDate of the next progress note that gets printed.

For example:

First note in printed output--
SrvDate in Page Header: 9/5/06
SrvDate in Page Footer (signature line): 9/7/06

Second note --
SrvDate in Page Header: 9/7/06
SrvDate in Page Footer: 9/10/06

Third note --
SrvDate in Page Header: 9/10/06
SrvDate in Page Footer: 9/10/06

Fourth note --
SrvDate in Page Header: 9/10/06
SrvDate in Page Footer: 9/15/06

... again, this error does not occur on the desktop computers.

I'm not sure I followed all of the above, but it seems me that the
SrvDate that will be printed will be the one drawn from the first
record printed in the detail of the start of the group, or of the
group repeat at the start of the next page.

That's the way it *ought* to work.

If I understand correctly, that would mean that the only PC printing
correctly is the *laptop*, which is just the same problem turned on
its head.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[cmd]

It just occurred to me that it can't be the network hardware ...
(whew!) ... I had looked at the reports in Print Preview on the laptop
and the errors were there in Print Preview. The laptop has an FE linked
to a local BE, not the network BE -- so, the network was not involved
at this point.

David W. Fenton wrote:

cm*@mountain.net wrote in
news:11**********************@i3g2000cwc.googlegro ups.com:

The sections of the report are:

Report Header (empty)
Page Header (client name, type of service, date of service, etc.)
DapID Header (visible: no)
Detail (memo fields)
DapID Footer (visible: no; force new page: after section)
Page Footer (name of staff, signature line, date of service)
Report Header (empty)

The notes are being printed in the correct order. The error that
seems to be occurring on some of the laptops is that SrvDate (date
of service) is frequently being misprinted in the Page Footer.
Instead of matching SrvDate in the Page Header, it seems to match
the SrvDate of the next progress note that gets printed.

For example:

First note in printed output--
SrvDate in Page Header: 9/5/06
SrvDate in Page Footer (signature line): 9/7/06

Second note --
SrvDate in Page Header: 9/7/06
SrvDate in Page Footer: 9/10/06

Third note --
SrvDate in Page Header: 9/10/06
SrvDate in Page Footer: 9/10/06

Fourth note --
SrvDate in Page Header: 9/10/06
SrvDate in Page Footer: 9/15/06

... again, this error does not occur on the desktop computers.

I'm not sure I followed all of the above, but it seems me that the
SrvDate that will be printed will be the one drawn from the first
record printed in the detail of the start of the group, or of the
group repeat at the start of the next page.

That's the way it *ought* to work.

If I understand correctly, that would mean that the only PC printing
correctly is the *laptop*, which is just the same problem turned on
its head.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[cmd]

David,
I just figured out that Access10 is simply processing the report
differently than Access97. I revamped the report to be based on a temp
table. This temp table contains all the desired records placed there in
the correct sort order by an append query. The temp table has an
autonumber primary key (DapID), which is used as the sort order for the
report. This *does* print the progress notes in the correct order, but
the wrong date in the Page Footer continues to be a problem on the
Access10 machines. In fact, *any* field that I copy from the Page
Header section to the Page Footer section ends up coming from the
*next* record in the table, rather than the current current as
displayed in the Page Header.

The layout for the report is as follows:

Report Header (empty)
Page Header (client name, type of service, date of service, etc.)
DapID Header (visible: no)
Detail (memo fields)
DapID Footer (visible: no; force new page: after section)
Page Footer (name of staff, signature line, date of service)
Report Header (empty)

In Access97 (where I do most of my development), the fields in the Page
Footer and the fields in the Page Header come from the same record. In
Access10, the fields in the Page Footer (with the design that I've
used) come from the *next* record following the record printed in the
Page Header.

Thus, it's a design problem ... not one of RAM, or References, or
printer drivers, or network hardware.

What I want to do, and what I *can* do in Access97, is to batch-print a
group of progress notes. Each note is a single record in the table,
distinguished by the primary key (DapID). Each note needs fields from
that particular record placed in both the Page Header *and* Page
Footer. Each note needs to begin on a separate page, but a particular
note may span more than one page and, if it does, needs to have the
same info in the Footer and Header.

Is this still possible in Access10, like it evidently is in Access97? I
hope so -- otherwise, staff either have to go back to manually printing
each of their 60-70 progress notes, or I have to import and print their
notes from my Access97 computer.

Thanks,
Mark

David W. Fenton wrote:

cm*@mountain.net wrote in
news:11**********************@i3g2000cwc.googlegro ups.com:

The sections of the report are:

Report Header (empty)
Page Header (client name, type of service, date of service, etc.)
DapID Header (visible: no)
Detail (memo fields)
DapID Footer (visible: no; force new page: after section)
Page Footer (name of staff, signature line, date of service)
Report Header (empty)

The notes are being printed in the correct order. The error that
seems to be occurring on some of the laptops is that SrvDate (date
of service) is frequently being misprinted in the Page Footer.
Instead of matching SrvDate in the Page Header, it seems to match
the SrvDate of the next progress note that gets printed.

For example:

First note in printed output--
SrvDate in Page Header: 9/5/06
SrvDate in Page Footer (signature line): 9/7/06

Second note --
SrvDate in Page Header: 9/7/06
SrvDate in Page Footer: 9/10/06

Third note --
SrvDate in Page Header: 9/10/06
SrvDate in Page Footer: 9/10/06

Fourth note --
SrvDate in Page Header: 9/10/06
SrvDate in Page Footer: 9/15/06

... again, this error does not occur on the desktop computers.

I'm not sure I followed all of the above, but it seems me that the
SrvDate that will be printed will be the one drawn from the first
record printed in the detail of the start of the group, or of the
group repeat at the start of the next page.

That's the way it *ought* to work.

If I understand correctly, that would mean that the only PC printing
correctly is the *laptop*, which is just the same problem turned on
its head.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

cm*@mountain.net wrote in
news:11**********************@i3g2000cwc.googlegro ups.com:

I just figured out that Access10 is simply processing the report
differently than Access97.

Do you have different versions of Access here? Or are you just
saying that report processing has changed between the two versions?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[cmd]

David,
The Access10 versions are all the same, as well as the operating
systems, service packs, jet versions, and references. On all the
Access10 machines, the report produces the errors as described
previously. The report works perfectly (or, at least as I had intended
it to work) on any Access97 computer.
Thanks,
Mark

David W. Fenton wrote:

cm*@mountain.net wrote in
news:11**********************@i3g2000cwc.googlegro ups.com:

I just figured out that Access10 is simply processing the report
differently than Access97.

Do you have different versions of Access here? Or are you just
saying that report processing has changed between the two versions?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Bob Quintal]

cm*@mountain.net wrote in
news:11**********************@i3g2000cwc.googlegro ups.com:

David,
I just figured out that Access10 is simply processing the
report differently than Access97. I revamped the report to be
based on a temp table. This temp table contains all the
desired records placed there in the correct sort order by an
append query. The temp table has an autonumber primary key
(DapID), which is used as the sort order for the report. This
*does* print the progress notes in the correct order, but the
wrong date in the Page Footer continues to be a problem on the
Access10 machines. In fact, *any* field that I copy from the
Page Header section to the Page Footer section ends up coming
from the *next* record in the table, rather than the current
current as displayed in the Page Header.

The layout for the report is as follows:

Report Header (empty)
Page Header (client name, type of service, date of service,
etc.) DapID Header (visible: no)
Detail (memo fields)
DapID Footer (visible: no; force new page: after section)
Page Footer (name of staff, signature line, date of
service) Report Header (empty)

In Access97 (where I do most of my development), the fields in
the Page Footer and the fields in the Page Header come from
the same record. In Access10, the fields in the Page Footer
(with the design that I've used) come from the *next* record
following the record printed in the Page Header.

Thus, it's a design problem ... not one of RAM, or References,
or printer drivers, or network hardware.

eek. a bug?

Workaround: define a variable in the code module's header,
before any sub statements. set the variable in the report's page
header on_format event. Print the variable in the page footer.

--
Bob Quintal

PA is y I've altered my email address.

--
Posted via a free Usenet account from http://www.teranews.com

[cmd]

Thanks for the suggestion, Bob.
I thought I might have to resort to code, but I'm just wanting to make
sure I didn't miss something in the switch from Access97 to Access10.
Mark

Bob Quintal wrote:

cm*@mountain.net wrote in
news:11**********************@i3g2000cwc.googlegro ups.com:

David,
I just figured out that Access10 is simply processing the
report differently than Access97. I revamped the report to be
based on a temp table. This temp table contains all the
desired records placed there in the correct sort order by an
append query. The temp table has an autonumber primary key
(DapID), which is used as the sort order for the report. This
*does* print the progress notes in the correct order, but the
wrong date in the Page Footer continues to be a problem on the
Access10 machines. In fact, *any* field that I copy from the
Page Header section to the Page Footer section ends up coming
from the *next* record in the table, rather than the current
current as displayed in the Page Header.

The layout for the report is as follows:

Report Header (empty)
Page Header (client name, type of service, date of service,
etc.) DapID Header (visible: no)
Detail (memo fields)
DapID Footer (visible: no; force new page: after section)
Page Footer (name of staff, signature line, date of
service) Report Header (empty)

In Access97 (where I do most of my development), the fields in
the Page Footer and the fields in the Page Header come from
the same record. In Access10, the fields in the Page Footer
(with the design that I've used) come from the *next* record
following the record printed in the Page Header.

Thus, it's a design problem ... not one of RAM, or References,
or printer drivers, or network hardware.

eek. a bug?

Workaround: define a variable in the code module's header,
before any sub statements. set the variable in the report's page
header on_format event. Print the variable in the page footer.

--
Bob Quintal

PA is y I've altered my email address.

--
Posted via a free Usenet account from http://www.teranews.com

[cmd]

Bob,
I could use some further help, if you please.
When you say "define the variable", do you mean something like: "Dim
MyDate As Date"?
And, what is the "code module's header"? -- where exactly do I place
this Dim statement -- the On_Format event of the Page Header?

Lastly, to "set the variable" do you mean something like: "MyDate =
...." ? -- I'm not sure if this would be something like: "MyDate =
Me!SrvDate" ... [SrvDate is the actual date field]

Thanks,
Mark

Bob Quintal wrote:

cm*@mountain.net wrote in
news:11**********************@i3g2000cwc.googlegro ups.com:

David,
I just figured out that Access10 is simply processing the
report differently than Access97. I revamped the report to be
based on a temp table. This temp table contains all the
desired records placed there in the correct sort order by an
append query. The temp table has an autonumber primary key
(DapID), which is used as the sort order for the report. This
*does* print the progress notes in the correct order, but the
wrong date in the Page Footer continues to be a problem on the
Access10 machines. In fact, *any* field that I copy from the
Page Header section to the Page Footer section ends up coming
from the *next* record in the table, rather than the current
current as displayed in the Page Header.

The layout for the report is as follows:

Report Header (empty)
Page Header (client name, type of service, date of service,
etc.) DapID Header (visible: no)
Detail (memo fields)
DapID Footer (visible: no; force new page: after section)
Page Footer (name of staff, signature line, date of
service) Report Header (empty)

In Access97 (where I do most of my development), the fields in
the Page Footer and the fields in the Page Header come from
the same record. In Access10, the fields in the Page Footer
(with the design that I've used) come from the *next* record
following the record printed in the Page Header.

Thus, it's a design problem ... not one of RAM, or References,
or printer drivers, or network hardware.

eek. a bug?

Workaround: define a variable in the code module's header,
before any sub statements. set the variable in the report's page
header on_format event. Print the variable in the page footer.

--
Bob Quintal

PA is y I've altered my email address.

--
Posted via a free Usenet account from http://www.teranews.com

[cmd]

Bob,
I don't know if this is correct:
I placed an unbound text box in the Page Footer and this code in the
On_Format event of the Page Header:

Private Sub PageHeader_Format(cancel As Integer, FormatCount As
Integer)
Dim MyDate As Date
MyDate = Me!DateProvSrv
Me!Text175 = MyDate
End Sub

.... it produces the right value in the Page Footer, but then I'm
currently working at home on an Access97 computer and I won't be able
to see if it works correctly in the Page Footer until I try it on
Access10 tomorrow.
Thanks,
Mark

Bob Quintal wrote:

cm*@mountain.net wrote in
news:11**********************@i3g2000cwc.googlegro ups.com:

David,
I just figured out that Access10 is simply processing the
report differently than Access97. I revamped the report to be
based on a temp table. This temp table contains all the
desired records placed there in the correct sort order by an
append query. The temp table has an autonumber primary key
(DapID), which is used as the sort order for the report. This
*does* print the progress notes in the correct order, but the
wrong date in the Page Footer continues to be a problem on the
Access10 machines. In fact, *any* field that I copy from the
Page Header section to the Page Footer section ends up coming
from the *next* record in the table, rather than the current
current as displayed in the Page Header.

The layout for the report is as follows:

Report Header (empty)
Page Header (client name, type of service, date of service,
etc.) DapID Header (visible: no)
Detail (memo fields)
DapID Footer (visible: no; force new page: after section)
Page Footer (name of staff, signature line, date of
service) Report Header (empty)

In Access97 (where I do most of my development), the fields in
the Page Footer and the fields in the Page Header come from
the same record. In Access10, the fields in the Page Footer
(with the design that I've used) come from the *next* record
following the record printed in the Page Header.

Thus, it's a design problem ... not one of RAM, or References,
or printer drivers, or network hardware.

eek. a bug?

Workaround: define a variable in the code module's header,
before any sub statements. set the variable in the report's page
header on_format event. Print the variable in the page footer.

--
Bob Quintal

PA is y I've altered my email address.

--
Posted via a free Usenet account from http://www.teranews.com

[cmd]

Yes, the code below enabled the Access10 computers to print the reports
with the correct data in the Page Footer. Thanks for your suggestion.
I'm still curious as to what was happening. Is printing a separate page
for each row in a recordset that unusual? Or, is there just something
screwy about how I designed the report?

code:
Dim MyDate As Date
MyDate = Me!DateProvSrv
Me!Text175 = MyDate

again, thanks
mark
Bob Quintal wrote:

cm*@mountain.net wrote in
news:11**********************@i3g2000cwc.googlegro ups.com:

David,
I just figured out that Access10 is simply processing the
report differently than Access97. I revamped the report to be
based on a temp table. This temp table contains all the
desired records placed there in the correct sort order by an
append query. The temp table has an autonumber primary key
(DapID), which is used as the sort order for the report. This
*does* print the progress notes in the correct order, but the
wrong date in the Page Footer continues to be a problem on the
Access10 machines. In fact, *any* field that I copy from the
Page Header section to the Page Footer section ends up coming
from the *next* record in the table, rather than the current
current as displayed in the Page Header.

The layout for the report is as follows:

Report Header (empty)
Page Header (client name, type of service, date of service,
etc.) DapID Header (visible: no)
Detail (memo fields)
DapID Footer (visible: no; force new page: after section)
Page Footer (name of staff, signature line, date of
service) Report Header (empty)

In Access97 (where I do most of my development), the fields in
the Page Footer and the fields in the Page Header come from
the same record. In Access10, the fields in the Page Footer
(with the design that I've used) come from the *next* record
following the record printed in the Page Header.

Thus, it's a design problem ... not one of RAM, or References,
or printer drivers, or network hardware.

eek. a bug?

Workaround: define a variable in the code module's header,
before any sub statements. set the variable in the report's page
header on_format event. Print the variable in the page footer.

--
Bob Quintal

PA is y I've altered my email address.

--
Posted via a free Usenet account from http://www.teranews.com

[David W. Fenton]

cm*@mountain.net wrote in
news:11**********************@h48g2000cwc.googlegr oups.com:

Yes, the code below enabled the Access10 computers to print the
reports with the correct data in the Page Footer. Thanks for your
suggestion. I'm still curious as to what was happening. Is
printing a separate page for each row in a recordset that unusual?
Or, is there just something screwy about how I designed the
report?

I think there must have been a change when the report moves to the
next record. It looks like it does it after the printing of the last
detail record and before the printing of the page footer, if I'm
remembering the details of your problem correctly.

Another trick would be to use in the footer the value in the
*control* in the header that has the date value. That would save
coding.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

cm*@mountain.net wrote in
news:11**********************@h48g2000cwc.googlegr oups.com:

Yes, the code below enabled the Access10 computers to print the
reports with the correct data in the Page Footer. Thanks for your
suggestion. I'm still curious as to what was happening. Is
printing a separate page for each row in a recordset that unusual?
Or, is there just something screwy about how I designed the
report?

I think one of the problems here, if I'm recalling all the details
correctly, is that you're doing things wrong. For printing *data*
from the records, you should use the detail and the grouping
headers. You don't have much control over which records are current
at the time the page headers/footers are formatted. This is,
perhaps, one of the reasons no one else seems to have encountered
your problem.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[cmd]

Yes, I can see how that would also work.
Is this a bug in Access10?
Also, now that I have a fix for the problem, should I consider undoing
the use of a temp table? Previously, I let the report itself do all the
sorting (client name, date, time) ... now I base the report on a temp
table where the sorting has already been done (as described previously
in this thread). Does the use of the temp table result in more
efficient processing and printing of the report(s), or doesn't it
matter?
Thanks,
Mark

David W. Fenton wrote:

cm*@mountain.net wrote in
news:11**********************@h48g2000cwc.googlegr oups.com:

Yes, the code below enabled the Access10 computers to print the
reports with the correct data in the Page Footer. Thanks for your
suggestion. I'm still curious as to what was happening. Is
printing a separate page for each row in a recordset that unusual?
Or, is there just something screwy about how I designed the
report?

I think there must have been a change when the report moves to the
next record. It looks like it does it after the printing of the last
detail record and before the printing of the page footer, if I'm
remembering the details of your problem correctly.

Another trick would be to use in the footer the value in the
*control* in the header that has the date value. That would save
coding.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[cmd]

Just saw this post, David
Ok, evidently there was much more latitude in Access97 for the kind of
poor design that I get into sometimes. I never realized there could be
a problem with page headers/footers and current records/detail
sections. I just assumed you could toss the fields from the current
record anywhere on the page.

David W. Fenton wrote:

cm*@mountain.net wrote in
news:11**********************@h48g2000cwc.googlegr oups.com:

Yes, the code below enabled the Access10 computers to print the
reports with the correct data in the Page Footer. Thanks for your
suggestion. I'm still curious as to what was happening. Is
printing a separate page for each row in a recordset that unusual?
Or, is there just something screwy about how I designed the
report?

I think one of the problems here, if I'm recalling all the details
correctly, is that you're doing things wrong. For printing *data*
from the records, you should use the detail and the grouping
headers. You don't have much control over which records are current
at the time the page headers/footers are formatted. This is,
perhaps, one of the reasons no one else seems to have encountered
your problem.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Bob Quintal]

cm*@mountain.net wrote in
news:11**********************@k70g2000cwa.googlegr oups.com:

Bob,
I could use some further help, if you please.
When you say "define the variable", do you mean something
like: "Dim MyDate As Date"?

Exactly

And, what is the "code module's header"? -- where exactly do I
place this Dim statement -- the On_Format event of the Page
Header?

The form has a code module.By header I mean the section above
the first sub or function declaration.
If you place a Dim statement inside a sub or function, its scope
of availability is limited to within that sub. If you place it
before any sub definitions it is available to all the subs and
functions in the module

In this case, you are seting the variable in the Header's
OnFormat and displaying it in the Footer's OnFormat so it needs
to be Dim-ed before the subs.

>
Lastly, to "set the variable" do you mean something like:
"MyDate = ..." ? -- I'm not sure if this would be something
like: "MyDate = Me!SrvDate" ... [SrvDate is the actual date
field]

Yes.

>
Thanks,
Mark

You're welcome.
Bob

Bob Quintal wrote:

>cm*@mountain.net wrote in
news:11**********************@i3g2000cwc.googlegr oups.com:

David,
I just figured out that Access10 is simply processing the
report differently than Access97. I revamped the report to
be based on a temp table. This temp table contains all the
desired records placed there in the correct sort order by
an append query. The temp table has an autonumber primary
key (DapID), which is used as the sort order for the
report. This *does* print the progress notes in the correct
order, but the wrong date in the Page Footer continues to
be a problem on the Access10 machines. In fact, *any* field
that I copy from the Page Header section to the Page Footer
section ends up coming from the *next* record in the table,
rather than the current current as displayed in the Page
Header.

The layout for the report is as follows:

Report Header (empty)
Page Header (client name, type of service, date of
service, etc.) DapID Header (visible: no)
Detail (memo fields)
DapID Footer (visible: no; force new page: after
section) Page Footer (name of staff, signature line,
date of service) Report Header (empty)

In Access97 (where I do most of my development), the fields
in the Page Footer and the fields in the Page Header come
from the same record. In Access10, the fields in the Page
Footer (with the design that I've used) come from the
*next* record following the record printed in the Page
Header.

Thus, it's a design problem ... not one of RAM, or
References, or printer drivers, or network hardware.

eek. a bug?

Workaround: define a variable in the code module's header,
before any sub statements. set the variable in the report's
page header on_format event. Print the variable in the page
footer.

--
Bob Quintal

PA is y I've altered my email address.

--
Posted via a free Usenet account from http://www.teranews.com

--
Bob Quintal

PA is y I've altered my email address.

--
Posted via a free Usenet account from http://www.teranews.com

[David W. Fenton]

cm*@mountain.net wrote in
news:11**********************@k70g2000cwa.googlegr oups.com:

Is this a bug in Access10?

I can't say. It's different. It's kind of like depending on an
underlying sort order to produce the correct sort in a datasheet,
instead of explicitly setting the Order By property. In some cases
it will work, in others it won't. I don't know why it always worked
in A97, and doesn't now. But that's perhaps because I never tried
what you were doing.

Perhaps the decoupling of A2K from Jet has caused this kind of
thing.

Also, now that I have a fix for the problem, should I consider
undoing the use of a temp table? Previously, I let the report
itself do all the sorting (client name, date, time) ... now I base
the report on a temp table where the sorting has already been done
(as described previously in this thread). Does the use of the temp
table result in more efficient processing and printing of the
report(s), or doesn't it matter?

Temp files can improve performance if the original recordsource ran
very slowly. If not, it won't improve it. I'd probably return to the
non-temp table solution if the original was not slow.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[cmd]

Thanks, David ... I appreciate the info & advice
Mark

David W. Fenton wrote:

cm*@mountain.net wrote in
news:11**********************@k70g2000cwa.googlegr oups.com:

Is this a bug in Access10?

I can't say. It's different. It's kind of like depending on an
underlying sort order to produce the correct sort in a datasheet,
instead of explicitly setting the Order By property. In some cases
it will work, in others it won't. I don't know why it always worked
in A97, and doesn't now. But that's perhaps because I never tried
what you were doing.

Perhaps the decoupling of A2K from Jet has caused this kind of
thing.

Also, now that I have a fix for the problem, should I consider
undoing the use of a temp table? Previously, I let the report
itself do all the sorting (client name, date, time) ... now I base
the report on a temp table where the sorting has already been done
(as described previously in this thread). Does the use of the temp
table result in more efficient processing and printing of the
report(s), or doesn't it matter?

Temp files can improve performance if the original recordsource ran
very slowly. If not, it won't improve it. I'd probably return to the
non-temp table solution if the original was not slow.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[cmd]

David, just an FYI ...
I named the date field in the Page Header as "DatePageHeader". I set
the control in the Page Footer as: =[DatePageHeader]. This resulted in
the same error in Access10, so I've returned to the use of a temp
table.

.... come to think of it, however, I could still eliminate the temp
table -- it's not the source of the records that matters, it's the code
in the Page Header On_Format event that apparently makes it work in
Access10.

Mark

David W. Fenton wrote:

cm*@mountain.net wrote in
news:11**********************@k70g2000cwa.googlegr oups.com:

Is this a bug in Access10?

I can't say. It's different. It's kind of like depending on an
underlying sort order to produce the correct sort in a datasheet,
instead of explicitly setting the Order By property. In some cases
it will work, in others it won't. I don't know why it always worked
in A97, and doesn't now. But that's perhaps because I never tried
what you were doing.

Perhaps the decoupling of A2K from Jet has caused this kind of
thing.

Also, now that I have a fix for the problem, should I consider
undoing the use of a temp table? Previously, I let the report
itself do all the sorting (client name, date, time) ... now I base
the report on a temp table where the sorting has already been done
(as described previously in this thread). Does the use of the temp
table result in more efficient processing and printing of the
report(s), or doesn't it matter?

Temp files can improve performance if the original recordsource ran
very slowly. If not, it won't improve it. I'd probably return to the
non-temp table solution if the original was not slow.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/