Form Data to Report Data

I am sure I am making a newbie mistake, but I think I have a legitamate
problem getting data from a form to a report.

I have a very complex UNBOUND access form and it has several command buttons
that spawn a few different reports. I know that generally reports have to
open a form to get data, but in my case, all the work is done by THE FORM and
its module.

As far as I can tell, the only way to get data from the form/module is to
write the data to the database and then open the report bound to the database.

Someone please tell me this is too much work and there is an easier way. I
have tried to access the form data from the report, but the data in the form
seems to be out of scope for the report.

Help!

A) Is the form open? It must be for this to work.

B) How are you attempting to refer to the form's controls? Standard syntax is
[Forms]![YourFormName]![TheControlName]
That should return the value in the control of the open form.

C) You mention getting data from the form's module. Do you mean that you are
populating variables and want the report or an underlying query to see those
variables? If so, the easiest method is to add some controls to THE FORM and
set the value of the controls to the value of the variables. You can set the
control's visible property to false if you don't want them visible.

If none of the above apply, can you give a little more detail on what you are doing.

Rob G wrote:

I am sure I am making a newbie mistake, but I think I have a legitamate
problem getting data from a form to a report.

I have a very complex UNBOUND access form and it has several command buttons
that spawn a few different reports. I know that generally reports have to
open a form to get data, but in my case, all the work is done by THE FORM and
its module.

As far as I can tell, the only way to get data from the form/module is to
write the data to the database and then open the report bound to the database.

Someone please tell me this is too much work and there is an easier way. I
have tried to access the form data from the report, but the data in the form
seems to be out of scope for the report.

Help!

Rob G wrote:

I am sure I am making a newbie mistake, but I think I have a legitamate
problem getting data from a form to a report.

I have a very complex UNBOUND access form and it has several command buttons
that spawn a few different reports. I know that generally reports have to
open a form to get data, but in my case, all the work is done by THE FORM and
its module.

As far as I can tell, the only way to get data from the form/module is to
write the data to the database and then open the report bound to the database.

Someone please tell me this is too much work and there is an easier way. I
have tried to access the form data from the report, but the data in the form
seems to be out of scope for the report.


It's certainly more in keeping with a database system to put
the data in a table. But Access is a very versatile set of
tools and an unbound report is not unheard of.

If the report can live within the design limits of 200" high
(using a bunch of sections), then you can easily lay it out
using text boxes with references to the form's controls:
=Forms!theform.controlname
If that's the kind of thing you tried, then you'll have to
post more details before we can figure out what your problem
is.

Things get trickier as you try to expand on this basic
approach.

--
Marsh
MVP [MS Access]

Thank you both for your replies. The form is still open and I have tried to
set up a simple example using one text box from the form as a prototype for
this problem.

Private Sub Detail_Format(Cancel As Integer, FormatCount As Integer)
Me.LabelTEST = Forms!MyForm.MyName
Me.LabelTEST = Forms!MyForm!MyName
End Sub

Both for lines of code yield the dreaded "Run-time error '-2147352567
(80020009)': The value you entered isn't valid for this field."

John's question in part C) All the form's business logic and data come from
the module. The data that the end user adds to the form gets copied and
manipulated in the module causing other values to change and ultimately some
sections of the form get refreshed. The the user is done putting in the
data, they choose a report as a view of that data. The goal is to have them
print that report and then I'll write the appropriate data to the database
from within the module and close the form.

Sometimes a user has to see their work before they accept the data and want
to commit it to the database.

I hope I answered your questions and tried to keep the focus on a simple
example to which we can conquer the larger task.

Thank you.



"Marshall Barton" wrote:

Rob G wrote:

I am sure I am making a newbie mistake, but I think I have a legitamate
problem getting data from a form to a report.

I have a very complex UNBOUND access form and it has several command buttons
that spawn a few different reports. I know that generally reports have to
open a form to get data, but in my case, all the work is done by THE FORM and
its module.

As far as I can tell, the only way to get data from the form/module is to
write the data to the database and then open the report bound to the database.

Someone please tell me this is too much work and there is an easier way. I
have tried to access the form data from the report, but the data in the form
seems to be out of scope for the report.


It's certainly more in keeping with a database system to put
the data in a table. But Access is a very versatile set of
tools and an unbound report is not unheard of.

If the report can live within the design limits of 200" high
(using a bunch of sections), then you can easily lay it out
using text boxes with references to the form's controls:
=Forms!theform.controlname
If that's the kind of thing you tried, then you'll have to
post more details before we can figure out what your problem
is.

Things get trickier as you try to expand on this basic
approach.

--
Marsh
MVP [MS Access]

Is LabelTest a label control? If so, you can't assign a value to a label.
You can assign a value to the caption of the label.

Me.LabelTEST.Caption=Forms!MyForm!MyName

Just checking.
I note that your example does not use the [] around the reference to the
form control. I know this is not required with the sample names since you
did not have any spaces or other special characters in the name.


"Rob G" wrote in message
news
Thank you both for your replies. The form is still open and I have tried
to
set up a simple example using one text box from the form as a prototype
for
this problem.

Private Sub Detail_Format(Cancel As Integer, FormatCount As Integer)
Me.LabelTEST = Forms!MyForm.MyName
Me.LabelTEST = Forms!MyForm!MyName
End Sub

Both for lines of code yield the dreaded "Run-time error '-2147352567
(80020009)': The value you entered isn't valid for this field."

John's question in part C) All the form's business logic and data come
from
the module. The data that the end user adds to the form gets copied and
manipulated in the module causing other values to change and ultimately
some
sections of the form get refreshed. The the user is done putting in the
data, they choose a report as a view of that data. The goal is to have
them
print that report and then I'll write the appropriate data to the database
from within the module and close the form.

Sometimes a user has to see their work before they accept the data and
want
to commit it to the database.

I hope I answered your questions and tried to keep the focus on a simple
example to which we can conquer the larger task.

Thank you.



"Marshall Barton" wrote:

Rob G wrote:

I am sure I am making a newbie mistake, but I think I have a legitamate
problem getting data from a form to a report.

I have a very complex UNBOUND access form and it has several command
buttons
that spawn a few different reports. I know that generally reports have
to
open a form to get data, but in my case, all the work is done by THE
FORM and
its module.

As far as I can tell, the only way to get data from the form/module is
to
write the data to the database and then open the report bound to the
database.

Someone please tell me this is too much work and there is an easier way.
I
have tried to access the form data from the report, but the data in the
form
seems to be out of scope for the report.


It's certainly more in keeping with a database system to put
the data in a table. But Access is a very versatile set of
tools and an unbound report is not unheard of.

If the report can live within the design limits of 200" high
(using a bunch of sections), then you can easily lay it out
using text boxes with references to the form's controls:
=Forms!theform.controlname
If that's the kind of thing you tried, then you'll have to
post more details before we can figure out what your problem
is.

Things get trickier as you try to expand on this basic
approach.

--
Marsh
MVP [MS Access]

Unfortunately this is just a poorly named text box for this example.

"John Spencer" wrote:

Is LabelTest a label control? If so, you can't assign a value to a label.
You can assign a value to the caption of the label.

Me.LabelTEST.Caption=Forms!MyForm!MyName

Just checking.
I note that your example does not use the [] around the reference to the
form control. I know this is not required with the sample names since you
did not have any spaces or other special characters in the name.


"Rob G" wrote in message
news
Thank you both for your replies. The form is still open and I have tried
to
set up a simple example using one text box from the form as a prototype
for
this problem.

Private Sub Detail_Format(Cancel As Integer, FormatCount As Integer)
Me.LabelTEST = Forms!MyForm.MyName
Me.LabelTEST = Forms!MyForm!MyName
End Sub

Both for lines of code yield the dreaded "Run-time error '-2147352567
(80020009)': The value you entered isn't valid for this field."

John's question in part C) All the form's business logic and data come
from
the module. The data that the end user adds to the form gets copied and
manipulated in the module causing other values to change and ultimately
some
sections of the form get refreshed. The the user is done putting in the
data, they choose a report as a view of that data. The goal is to have
them
print that report and then I'll write the appropriate data to the database
from within the module and close the form.

Sometimes a user has to see their work before they accept the data and
want
to commit it to the database.

I hope I answered your questions and tried to keep the focus on a simple
example to which we can conquer the larger task.

Thank you.



"Marshall Barton" wrote:

Rob G wrote:

I am sure I am making a newbie mistake, but I think I have a legitamate
problem getting data from a form to a report.

I have a very complex UNBOUND access form and it has several command
buttons
that spawn a few different reports. I know that generally reports have
to
open a form to get data, but in my case, all the work is done by THE
FORM and
its module.

As far as I can tell, the only way to get data from the form/module is
to
write the data to the database and then open the report bound to the
database.

Someone please tell me this is too much work and there is an easier way.
I
have tried to access the form data from the report, but the data in the
form
seems to be out of scope for the report.


It's certainly more in keeping with a database system to put
the data in a table. But Access is a very versatile set of
tools and an unbound report is not unheard of.

If the report can live within the design limits of 200" high
(using a bunch of sections), then you can easily lay it out
using text boxes with references to the form's controls:
=Forms!theform.controlname
If that's the kind of thing you tried, then you'll have to
post more details before we can figure out what your problem
is.

Things get trickier as you try to expand on this basic
approach.

--
Marsh
MVP [MS Access]

In your test are you using a newly created form and newly created report? I
think you are from what your code looks like.

If you are, then I suspect that your database has become corrupted and/or
that the Name Autocorrect feature has struck yet again.

Quoting MVP Allen Browne
'========================================
Here is a standard sequence to try to rescue a corrupted mdb

0. Make a backup copy of the file.
00. Make a backup copy of the file.

1. Uncheck the boxes under:
Tools | Options | General | Name AutoCorrect
Explanation of why: http://allenbrowne.com/bug-03.html

2. Compact the database to get rid of this junk:
Tools | Database Utilities | Compact

3. Close Access. Make a backup copy of the file.
Decompile the database by entering something like this at the command
prompt while Access is not running. It is all one line, and includes the
quotes:
"c:\Program Files\Microsoft office\office\msaccess.exe" /decompile
"c:\MyPath\MyDatabase.mdb"

4. Open Access, and compact again.

5. Open a code window.
Choose References from the Tools menu.
Uncheck any references you do not need.
For a list of the ones you typically need in your version of Access, see:
http://allenbrowne.com/ser-38.html

6. Still in the code window, choose Compile from the Debug menu.
Fix any errors, and repeat until it compiles okay.

At this point, you should have a database where the name-autocorrect errors
are gone, the indexes are repaired, inconsistencies between the text- and
compiled-versions of the code are fixed, and reference ambiguities are
resolved.

If it is still a problem, the next step would be to get Access to rebuild
the database for you. Follow the steps for the first symptom in this
article:
Recovering from Corruption
at:
http://allenbrowne.com/ser-47.html

--
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.
"Rob G" wrote in message
...
Unfortunately this is just a poorly named text box for this example.

"John Spencer" wrote:

Is LabelTest a label control? If so, you can't assign a value to a
label.
You can assign a value to the caption of the label.

Me.LabelTEST.Caption=Forms!MyForm!MyName

Just checking.
I note that your example does not use the [] around the reference to the
form control. I know this is not required with the sample names since
you
did not have any spaces or other special characters in the name.


"Rob G" wrote in message
news
Thank you both for your replies. The form is still open and I have
tried
to
set up a simple example using one text box from the form as a prototype
for
this problem.

Private Sub Detail_Format(Cancel As Integer, FormatCount As Integer)
Me.LabelTEST = Forms!MyForm.MyName
Me.LabelTEST = Forms!MyForm!MyName
End Sub

Both for lines of code yield the dreaded "Run-time error '-2147352567
(80020009)': The value you entered isn't valid for this field."

John's question in part C) All the form's business logic and data come
from
the module. The data that the end user adds to the form gets copied
and
manipulated in the module causing other values to change and ultimately
some
sections of the form get refreshed. The the user is done putting in
the
data, they choose a report as a view of that data. The goal is to have
them
print that report and then I'll write the appropriate data to the
database
from within the module and close the form.

Sometimes a user has to see their work before they accept the data and
want
to commit it to the database.

I hope I answered your questions and tried to keep the focus on a
simple
example to which we can conquer the larger task.

Thank you.



"Marshall Barton" wrote:

Rob G wrote:

I am sure I am making a newbie mistake, but I think I have a
legitamate
problem getting data from a form to a report.

I have a very complex UNBOUND access form and it has several command
buttons
that spawn a few different reports. I know that generally reports
have
to
open a form to get data, but in my case, all the work is done by THE
FORM and
its module.

As far as I can tell, the only way to get data from the form/module
is
to
write the data to the database and then open the report bound to the
database.

Someone please tell me this is too much work and there is an easier
way.
I
have tried to access the form data from the report, but the data in
the
form
seems to be out of scope for the report.


It's certainly more in keeping with a database system to put
the data in a table. But Access is a very versatile set of
tools and an unbound report is not unheard of.

If the report can live within the design limits of 200" high
(using a bunch of sections), then you can easily lay it out
using text boxes with references to the form's controls:
=Forms!theform.controlname
If that's the kind of thing you tried, then you'll have to
post more details before we can figure out what your problem
is.

Things get trickier as you try to expand on this basic
approach.

--
Marsh
MVP [MS Access]

I'll give it a shot.

"John Spencer" wrote:

In your test are you using a newly created form and newly created report? I
think you are from what your code looks like.

If you are, then I suspect that your database has become corrupted and/or
that the Name Autocorrect feature has struck yet again.

Quoting MVP Allen Browne
'========================================
Here is a standard sequence to try to rescue a corrupted mdb

0. Make a backup copy of the file.
00. Make a backup copy of the file.

1. Uncheck the boxes under:
Tools | Options | General | Name AutoCorrect
Explanation of why: http://allenbrowne.com/bug-03.html

2. Compact the database to get rid of this junk:
Tools | Database Utilities | Compact

3. Close Access. Make a backup copy of the file.
Decompile the database by entering something like this at the command
prompt while Access is not running. It is all one line, and includes the
quotes:
"c:\Program Files\Microsoft office\office\msaccess.exe" /decompile
"c:\MyPath\MyDatabase.mdb"

4. Open Access, and compact again.

5. Open a code window.
Choose References from the Tools menu.
Uncheck any references you do not need.
For a list of the ones you typically need in your version of Access, see:
http://allenbrowne.com/ser-38.html

6. Still in the code window, choose Compile from the Debug menu.
Fix any errors, and repeat until it compiles okay.

At this point, you should have a database where the name-autocorrect errors
are gone, the indexes are repaired, inconsistencies between the text- and
compiled-versions of the code are fixed, and reference ambiguities are
resolved.

If it is still a problem, the next step would be to get Access to rebuild
the database for you. Follow the steps for the first symptom in this
article:
Recovering from Corruption
at:
http://allenbrowne.com/ser-47.html

--
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.
"Rob G" wrote in message
...
Unfortunately this is just a poorly named text box for this example.

"John Spencer" wrote:

Is LabelTest a label control? If so, you can't assign a value to a
label.
You can assign a value to the caption of the label.

Me.LabelTEST.Caption=Forms!MyForm!MyName

Just checking.
I note that your example does not use the [] around the reference to the
form control. I know this is not required with the sample names since
you
did not have any spaces or other special characters in the name.


"Rob G" wrote in message
news Thank you both for your replies. The form is still open and I have
tried
to
set up a simple example using one text box from the form as a prototype
for
this problem.

Private Sub Detail_Format(Cancel As Integer, FormatCount As Integer)
Me.LabelTEST = Forms!MyForm.MyName
Me.LabelTEST = Forms!MyForm!MyName
End Sub

Both for lines of code yield the dreaded "Run-time error '-2147352567
(80020009)': The value you entered isn't valid for this field."

John's question in part C) All the form's business logic and data come
from
the module. The data that the end user adds to the form gets copied
and
manipulated in the module causing other values to change and ultimately
some
sections of the form get refreshed. The the user is done putting in
the
data, they choose a report as a view of that data. The goal is to have
them
print that report and then I'll write the appropriate data to the
database
from within the module and close the form.

Sometimes a user has to see their work before they accept the data and
want
to commit it to the database.

I hope I answered your questions and tried to keep the focus on a
simple
example to which we can conquer the larger task.

Thank you.



"Marshall Barton" wrote:

Rob G wrote:

I am sure I am making a newbie mistake, but I think I have a
legitamate
problem getting data from a form to a report.

I have a very complex UNBOUND access form and it has several command
buttons
that spawn a few different reports. I know that generally reports
have
to
open a form to get data, but in my case, all the work is done by THE
FORM and
its module.

As far as I can tell, the only way to get data from the form/module
is
to
write the data to the database and then open the report bound to the
database.

Someone please tell me this is too much work and there is an easier
way.
I
have tried to access the form data from the report, but the data in
the
form
seems to be out of scope for the report.


It's certainly more in keeping with a database system to put
the data in a table. But Access is a very versatile set of
tools and an unbound report is not unheard of.

If the report can live within the design limits of 200" high
(using a bunch of sections), then you can easily lay it out
using text boxes with references to the form's controls:
=Forms!theform.controlname
If that's the kind of thing you tried, then you'll have to
post more details before we can figure out what your problem
is.

Things get trickier as you try to expand on this basic
approach.

--
Marsh
MVP [MS Access]

Eureka! Brilliant!

"John Spencer" wrote:

In your test are you using a newly created form and newly created report? I
think you are from what your code looks like.

If you are, then I suspect that your database has become corrupted and/or
that the Name Autocorrect feature has struck yet again.

Quoting MVP Allen Browne
'========================================
Here is a standard sequence to try to rescue a corrupted mdb

0. Make a backup copy of the file.
00. Make a backup copy of the file.

1. Uncheck the boxes under:
Tools | Options | General | Name AutoCorrect
Explanation of why: http://allenbrowne.com/bug-03.html

2. Compact the database to get rid of this junk:
Tools | Database Utilities | Compact

3. Close Access. Make a backup copy of the file.
Decompile the database by entering something like this at the command
prompt while Access is not running. It is all one line, and includes the
quotes:
"c:\Program Files\Microsoft office\office\msaccess.exe" /decompile
"c:\MyPath\MyDatabase.mdb"

4. Open Access, and compact again.

5. Open a code window.
Choose References from the Tools menu.
Uncheck any references you do not need.
For a list of the ones you typically need in your version of Access, see:
http://allenbrowne.com/ser-38.html

6. Still in the code window, choose Compile from the Debug menu.
Fix any errors, and repeat until it compiles okay.

At this point, you should have a database where the name-autocorrect errors
are gone, the indexes are repaired, inconsistencies between the text- and
compiled-versions of the code are fixed, and reference ambiguities are
resolved.

If it is still a problem, the next step would be to get Access to rebuild
the database for you. Follow the steps for the first symptom in this
article:
Recovering from Corruption
at:
http://allenbrowne.com/ser-47.html

--
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.
"Rob G" wrote in message
...
Unfortunately this is just a poorly named text box for this example.

"John Spencer" wrote:

Is LabelTest a label control? If so, you can't assign a value to a
label.
You can assign a value to the caption of the label.

Me.LabelTEST.Caption=Forms!MyForm!MyName

Just checking.
I note that your example does not use the [] around the reference to the
form control. I know this is not required with the sample names since
you
did not have any spaces or other special characters in the name.


"Rob G" wrote in message
news Thank you both for your replies. The form is still open and I have
tried
to
set up a simple example using one text box from the form as a prototype
for
this problem.

Private Sub Detail_Format(Cancel As Integer, FormatCount As Integer)
Me.LabelTEST = Forms!MyForm.MyName
Me.LabelTEST = Forms!MyForm!MyName
End Sub

Both for lines of code yield the dreaded "Run-time error '-2147352567
(80020009)': The value you entered isn't valid for this field."

John's question in part C) All the form's business logic and data come
from
the module. The data that the end user adds to the form gets copied
and
manipulated in the module causing other values to change and ultimately
some
sections of the form get refreshed. The the user is done putting in
the
data, they choose a report as a view of that data. The goal is to have
them
print that report and then I'll write the appropriate data to the
database
from within the module and close the form.

Sometimes a user has to see their work before they accept the data and
want
to commit it to the database.

I hope I answered your questions and tried to keep the focus on a
simple
example to which we can conquer the larger task.

Thank you.



"Marshall Barton" wrote:

Rob G wrote:

I am sure I am making a newbie mistake, but I think I have a
legitamate
problem getting data from a form to a report.

I have a very complex UNBOUND access form and it has several command
buttons
that spawn a few different reports. I know that generally reports
have
to
open a form to get data, but in my case, all the work is done by THE
FORM and
its module.

As far as I can tell, the only way to get data from the form/module
is
to
write the data to the database and then open the report bound to the
database.

Someone please tell me this is too much work and there is an easier
way.
I
have tried to access the form data from the report, but the data in
the
form
seems to be out of scope for the report.


It's certainly more in keeping with a database system to put
the data in a table. But Access is a very versatile set of
tools and an unbound report is not unheard of.

If the report can live within the design limits of 200" high
(using a bunch of sections), then you can easily lay it out
using text boxes with references to the form's controls:
=Forms!theform.controlname
If that's the kind of thing you tried, then you'll have to
post more details before we can figure out what your problem
is.

Things get trickier as you try to expand on this basic
approach.

--
Marsh
MVP [MS Access]

SIGH of relief. Glad this solved it.

"Rob G" wrote in message
...
Eureka! Brilliant!

"John Spencer" wrote:

In your test are you using a newly created form and newly created report?
I
think you are from what your code looks like.

If you are, then I suspect that your database has become corrupted and/or
that the Name Autocorrect feature has struck yet again.

Quoting MVP Allen Browne
'========================================
Here is a standard sequence to try to rescue a corrupted mdb

0. Make a backup copy of the file.
00. Make a backup copy of the file.

1. Uncheck the boxes under:
Tools | Options | General | Name AutoCorrect
Explanation of why: http://allenbrowne.com/bug-03.html

2. Compact the database to get rid of this junk:
Tools | Database Utilities | Compact

3. Close Access. Make a backup copy of the file.
Decompile the database by entering something like this at the command
prompt while Access is not running. It is all one line, and includes the
quotes:
"c:\Program Files\Microsoft office\office\msaccess.exe" /decompile
"c:\MyPath\MyDatabase.mdb"

4. Open Access, and compact again.

5. Open a code window.
Choose References from the Tools menu.
Uncheck any references you do not need.
For a list of the ones you typically need in your version of Access, see:
http://allenbrowne.com/ser-38.html

6. Still in the code window, choose Compile from the Debug menu.
Fix any errors, and repeat until it compiles okay.

At this point, you should have a database where the name-autocorrect
errors
are gone, the indexes are repaired, inconsistencies between the text- and
compiled-versions of the code are fixed, and reference ambiguities are
resolved.

If it is still a problem, the next step would be to get Access to rebuild
the database for you. Follow the steps for the first symptom in this
article:
Recovering from Corruption
at:
http://allenbrowne.com/ser-47.html

--
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.
"Rob G" wrote in message
...
Unfortunately this is just a poorly named text box for this example.

"John Spencer" wrote:

Is LabelTest a label control? If so, you can't assign a value to a
label.
You can assign a value to the caption of the label.

Me.LabelTEST.Caption=Forms!MyForm!MyName

Just checking.
I note that your example does not use the [] around the reference to
the
form control. I know this is not required with the sample names since
you
did not have any spaces or other special characters in the name.


"Rob G" wrote in message
news Thank you both for your replies. The form is still open and I have
tried
to
set up a simple example using one text box from the form as a
prototype
for
this problem.

Private Sub Detail_Format(Cancel As Integer, FormatCount As Integer)
Me.LabelTEST = Forms!MyForm.MyName
Me.LabelTEST = Forms!MyForm!MyName
End Sub

Both for lines of code yield the dreaded "Run-time error
'-2147352567
(80020009)': The value you entered isn't valid for this field."

John's question in part C) All the form's business logic and data
come
from
the module. The data that the end user adds to the form gets copied
and
manipulated in the module causing other values to change and
ultimately
some
sections of the form get refreshed. The the user is done putting in
the
data, they choose a report as a view of that data. The goal is to
have
them
print that report and then I'll write the appropriate data to the
database
from within the module and close the form.

Sometimes a user has to see their work before they accept the data
and
want
to commit it to the database.

I hope I answered your questions and tried to keep the focus on a
simple
example to which we can conquer the larger task.

Thank you.



"Marshall Barton" wrote:

Rob G wrote:

I am sure I am making a newbie mistake, but I think I have a
legitamate
problem getting data from a form to a report.

I have a very complex UNBOUND access form and it has several
command
buttons
that spawn a few different reports. I know that generally reports
have
to
open a form to get data, but in my case, all the work is done by
THE
FORM and
its module.

As far as I can tell, the only way to get data from the
form/module
is
to
write the data to the database and then open the report bound to
the
database.

Someone please tell me this is too much work and there is an
easier
way.
I
have tried to access the form data from the report, but the data
in
the
form
seems to be out of scope for the report.


It's certainly more in keeping with a database system to put
the data in a table. But Access is a very versatile set of
tools and an unbound report is not unheard of.

If the report can live within the design limits of 200" high
(using a bunch of sections), then you can easily lay it out
using text boxes with references to the form's controls:
=Forms!theform.controlname
If that's the kind of thing you tried, then you'll have to
post more details before we can figure out what your problem
is.

Things get trickier as you try to expand on this basic
approach.

--
Marsh
MVP [MS Access]