By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,456 Members | 1,952 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,456 IT Pros & Developers. It's quick & easy.

A97 Problem: Aliased fields not available in Detail.Format event

P: n/a
I ran into a weird problem with a subreport with an OnFormat event
of the subreport detail. When I view the field list in report design
view, all the aliased fields in the recordsource are available. But
when the report runs, the aliased fields are inaccessible. Of
course, this is causing a problem with the report running, and I
can't figure it out.

I've decompiled, I've compacted, I've recreated the recordsource.
I've tried moving the field aliasing out of the recordsource and
into source queries. None of these things have made a difference.

The same subreport is running correctly in a different A97 MDB that
has the same basic structure. I assume that one of two things are
happening:

1. either the slight changes I made for the new MDB are causing the
problem somehow, OR

2. one or more of the source queries is not the same as in the
working version (even though I've imported all the source queries
from the working version).

Any ideas? I was intending to roll this out for the client before
noon today, but it's broken now, so I can't. :(

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Apr 18 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Hi David

Couple of possible issues here.

There is a problem with examining the Controls of a Section of a Report in
Access 97 on Windows XP. The low-down is:
http://support.microsoft.com/kb/278303/en-us

If that is not the issue, you are probably aware that Access has always had
a problem with referring to the fields of the report if they are not
represented by controls on the report. In many circumstances (particulary
where the fields have never been controls, or were added/changed later) the
optimizer seems not to even generate the fields, and so referring to them
generates an error. The workaround is to create controls to bind them to.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in message
news:Xn**********************************@127.0.0. 1...
I ran into a weird problem with a subreport with an OnFormat event
of the subreport detail. When I view the field list in report design
view, all the aliased fields in the recordsource are available. But
when the report runs, the aliased fields are inaccessible. Of
course, this is causing a problem with the report running, and I
can't figure it out.

I've decompiled, I've compacted, I've recreated the recordsource.
I've tried moving the field aliasing out of the recordsource and
into source queries. None of these things have made a difference.

The same subreport is running correctly in a different A97 MDB that
has the same basic structure. I assume that one of two things are
happening:

1. either the slight changes I made for the new MDB are causing the
problem somehow, OR

2. one or more of the source queries is not the same as in the
working version (even though I've imported all the source queries
from the working version).

Any ideas? I was intending to roll this out for the client before
noon today, but it's broken now, so I can't. :(

Apr 18 '06 #2

P: n/a
"Allen Browne" <Al*********@SeeSig.Invalid> wrote in
news:44***********************@per-qv1-newsreader-01.iinet.net.au:
Couple of possible issues here.

There is a problem with examining the Controls of a Section of a
Report in Access 97 on Windows XP. The low-down is:
http://support.microsoft.com/kb/278303/en-us
An odd problem, but it occurs on Win2K and WinXP. The article is
unclear about whether it should occur in Win2K.

In any event, I don't see that it has anything to do with it. The
code is this:

Private Sub Detail_Format(Cancel As Integer, FormatCount As Integer)
If Me!InvoiceNumber = Me!SortInvoice Then
Me!fldInvoiceNumber.TextAlign = 1
Else
Me!fldInvoiceNumber.TextAlign = 3
End If
End Sub

And I'm told that Me!SortInvoice (which is aliased in the form's
recordsource, since it's based on a field called InvoiceNumber in a
different table) does not exist.
If that is not the issue, you are probably aware that Access has
always had a problem with referring to the fields of the report if
they are not represented by controls on the report. In many
circumstances (particulary where the fields have never been
controls, or were added/changed later) the optimizer seems not to
even generate the fields, and so referring to them generates an
error. The workaround is to create controls to bind them to.


I have seen that in A2K, where I frequently have upgraded A97 apps
that then break in A2K. But in all cases, it was references to
fields in the recordsource of a subform from the parent form.

This is a case of a subreport where a field in the subreport's
recordsource is referred to in the OnFormat event of the detail of
itself. And the report runs perfectly in one MDB but breaks in
another, saying it can't find the field.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Apr 18 '06 #3

P: n/a
"Allen Browne" <Al*********@SeeSig.Invalid> wrote in
news:44***********************@per-qv1-newsreader-01.iinet.net.au:
If that is not the issue, you are probably aware that Access has
always had a problem with referring to the fields of the report if
they are not represented by controls on the report. In many
circumstances (particulary where the fields have never been
controls, or were added/changed later) the optimizer seems not to
even generate the fields, and so referring to them generates an
error. The workaround is to create controls to bind them to.


Well, that actually worked. I've never encountered this problem in
A97 before, and never in any version of Access when the reference is
within a single report (rather than between parent and child or vice
versa).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Apr 18 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.