Forms or Reports

[Cipher via AccessMonster.com]

Either "I" lack of understanding of Access or the Access designers have a
lack of understanding of User erquirements. I need to know if I understand
the basics of Access, such as:

Original Data:- For my application, this is a Text File generated by a Real-
Time Software DataLogger connected to an industrial process.

Tables:- For my application, these tables are generated by reading the
external Text Files. As it will be necessary for the User to access the data
in the Text FIles but to also edit this data, it is not possible to LINK the
external Text Files to the Tables because the data deeds to be edited and you
cannot edit external data with a LINKED Table.

Forms:_ For my application, these Forms allow me to alter the data in the
Tables. I can PRINT the Forms after the Forms have processed the data in the
Tables even though purists decry this activity as Reports are favoured...all
correct?

Well, I have a problem with this set-up and here is why:
EVERYTHING goes back to the original Text FIles which are the key to
everything. The Real-Time Software Datalogger (RTSG) constantly updates the
text files so the Access Database needs to constantly re-read these files
everytime it is loaded. Unfortunatly, without linking the files the user
needs to re-read the text files back-in each time the Access Database is
launched.

If the USER uses the Forms to edit/add/delete data from the tables, the USER
then needs to re-save the Tables as a seperate process. Access will not allow
the Form to be exported back into the External Text files directly as the
only choice for exporting to the original Text Files is to use FORMATTED TEXT
FILES with all the extra "Dashes" added.

So here is what the User has to do now:
1) Run Access and IMPORT the external Text Files into the Tables. As there
are Eleven (11) Text Files they all have to be done seperatly.

2) Launch the relavent Forms and process the data back to the Tables.

3) Then the USer has to re-save (Export) the Tables (eleven of them) back
into the External Text FIles. It must be noted at this time that the RTSG is
no longer running while data editing is being done so there is no conflict in
the External Data being changed while Access is operating on the data.

Would this be easier?: Launch the Access FORM and read in the data from the
external Text Files as required. The USER uses the Form to edit the data and
is finished. If all the information was linked back to the original External
Text Files all DATA FLOW would be automatic as the WHOLE f Text File would be
loaded, edited and then written back.

Is it possible? or are the Access Designers missing something

 

[Douglas J. Steele]

Comments in-line.

--
Doug Steele, Microsoft Access MVP

(no e-mails, please!)

Either "I" lack of understanding of Access or the Access designers have a
lack of understanding of User erquirements. I need to know if I understand
the basics of Access, such as:

Original Data:- For my application, this is a Text File generated by a
Real-
Time Software DataLogger connected to an industrial process.

Tables:- For my application, these tables are generated by reading the
external Text Files. As it will be necessary for the User to access the
data
in the Text FIles but to also edit this data, it is not possible to LINK
the
external Text Files to the Tables because the data deeds to be edited and
you
cannot edit external data with a LINKED Table.

Text files don't allow multiple users to update them. Because of that
limitation, there's no way for Access to update linked text files.

Forms:_ For my application, these Forms allow me to alter the data in the
Tables. I can PRINT the Forms after the Forms have processed the data in
the
Tables even though purists decry this activity as Reports are
favoured...all
correct?

While it's possible to print forms, why would you? You don't have much
control over how they print. As well, you lose the ability to include
grouping.

Well, I have a problem with this set-up and here is why:
EVERYTHING goes back to the original Text FIles which are the key to
everything. The Real-Time Software Datalogger (RTSG) constantly updates
the
text files so the Access Database needs to constantly re-read these files
everytime it is loaded. Unfortunatly, without linking the files the user
needs to re-read the text files back-in each time the Access Database is
launched.

You could link to the text files, and use the linked tables as the basis for
queries that refreshes the data in your Access tables. If you look at my
November, 2003 "Access Answers" column in Pinnacle Publication's "Smart
Access", you'll see how you can append new records and change existing
records with a single query. (You can download the column and sample
database for free at http://www.accessmvp.com/DJSteele/SmartAccess.html)

If the USER uses the Forms to edit/add/delete data from the tables, the
USER
then needs to re-save the Tables as a seperate process. Access will not
allow
the Form to be exported back into the External Text files directly as the
only choice for exporting to the original Text Files is to use FORMATTED
TEXT
FILES with all the extra "Dashes" added.

I don't understand this statement.

Forms don't have data: tables do. Using TransferText to export the data from
the tables doesn't limit you to formatted text files with dashes added.

So here is what the User has to do now:
1) Run Access and IMPORT the external Text Files into the Tables. As there
are Eleven (11) Text Files they all have to be done seperatly.

Hopefully you're not making the user import 11 times: that you're automating
the process for him/her!

2) Launch the relavent Forms and process the data back to the Tables.

3) Then the USer has to re-save (Export) the Tables (eleven of them) back
into the External Text FIles. It must be noted at this time that the RTSG
is
no longer running while data editing is being done so there is no conflict
in
the External Data being changed while Access is operating on the data.

Again, hopefully you've automated the process so that the user only has to
push a single button and all of the exports are done automatically.

 

[Cipher via AccessMonster.com]

1) When you say "You cannot EXPORT a Form", this is not true. You can export
the table connected to the Form but you are not EXPORTING the table directly.
If you look into EXPORT from the Form (Right CLICK the Form and select EXPORT)
it will allow you to export BACK to the original External Text File.
Unfortunately (if you look into this yourself) when you EXPORT through the
Form it produces a Text File which is Formatted and it fills the Text File
with Stupid Dashes.

2) You stated..."You could link to the text files", again this is not
possible because Access clearly states that 'Linked Files CANNOT be edited
and can ONLY be appended too". As the User wishes to edit the original Text
Files using your suggested method will not work.

3) You stated "Text files don't allow multiple users to update them. Because
of that
limitation, there's no way for Access to update linked text files" If you had
read my post before commenting, you would have seen that I clearly stated
that..."The RTSD will not be adding records to the Text Files while the user
is editing the files, so there is no conflict". This makes your comment
unnecessary

I am using a Form because the USER wishes to process data from External Text
FIles (single user, nobody else messing with the files, files are static,
there are no networks involved and there is only one computer and one person).
In order for the User to edit the information once it has been obtained, I am
using FORMS...is this not the purpose of a Form?

Once the USer is happy with the results, he/she will wish to print the
results to paper. I have two Forms, the first is a SIngle Computation
directly to the Form and I have placed a Print Form command button on the
Form for this purpose. All works well on the Single Computation Form.

The second Form is a little more complex as it is a Nested version of the
First Form. Each time the the Form processes information, I would like the
resulting Form to automatically print. Then the Form will automatically
generate the next set of data and the process will repeat. Unfortunatly, the
only command I can find is: RunCommand(acCmdPrint). This command invokes the
Print Dialog Box which forces the User to click PRINT each time the Form
recalculates.

There are NO references in any book, the Microsoft resourses on the Web that
indicate how data from a Form can be SAVED to a Report. I have heard that it
is possible to save a Form as a Report but I have no idea how and cannot find
any references as to how it is done.

When you examine the differences between Forms and Reports, the only real
difference is that a Form is more versatile. If Microsoft were to include the
same Printing and Formatting functionality in a Form as there is in a Report,
there would be no need to even have Reports.

Is there a better way?

Now, this is a comment to all who respond to these posts:
1) If a Poster posts information regarding a method of working Access is is
because things are not working as expected or desired.

2) If the comments come back as..."Why are you doing it that way"..."Access
provides a much better solution"..."I dont undestand why anybody would do it
that way"...Remember this, if there IS a better way, but we have not used it
it is because..."we did not know there was a better way, otherwise we would
have used it". So, please refraim from "Bombastigating" us and choose a
milder more constructive approach such as..."Although it is possible to do it
that way, my experience has tough me that this approach would yield better
results as follows", here you would provide either a LINK or a Code Fragment
to illustrate...THE BETTER WAY...Just a thought.

Comments in-line.

Either "I" lack of understanding of Access or the Access designers have a
lack of understanding of User erquirements. I need to know if I understand

[quoted text clipped - 12 lines]

you
cannot edit external data with a LINKED Table.

Text files don't allow multiple users to update them. Because of that
limitation, there's no way for Access to update linked text files.

Forms:_ For my application, these Forms allow me to alter the data in the
Tables. I can PRINT the Forms after the Forms have processed the data in
the
Tables even though purists decry this activity as Reports are
favoured...all
correct?

While it's possible to print forms, why would you? You don't have much
control over how they print. As well, you lose the ability to include
grouping.

Well, I have a problem with this set-up and here is why:
EVERYTHING goes back to the original Text FIles which are the key to

[quoted text clipped - 4 lines]

needs to re-read the text files back-in each time the Access Database is
launched.

You could link to the text files, and use the linked tables as the basis for
queries that refreshes the data in your Access tables. If you look at my
November, 2003 "Access Answers" column in Pinnacle Publication's "Smart
Access", you'll see how you can append new records and change existing
records with a single query. (You can download the column and sample
database for free at http://www.accessmvp.com/DJSteele/SmartAccess.html)

If the USER uses the Forms to edit/add/delete data from the tables, the
USER

[quoted text clipped - 4 lines]

TEXT
FILES with all the extra "Dashes" added.

I don't understand this statement.

Forms don't have data: tables do. Using TransferText to export the data from
the tables doesn't limit you to formatted text files with dashes added.

So here is what the User has to do now:
1) Run Access and IMPORT the external Text Files into the Tables. As there
are Eleven (11) Text Files they all have to be done seperatly.

Hopefully you're not making the user import 11 times: that you're automating
the process for him/her!

2) Launch the relavent Forms and process the data back to the Tables.

[quoted text clipped - 4 lines]

in
the External Data being changed while Access is operating on the data.

Again, hopefully you've automated the process so that the user only has to
push a single button and all of the exports are done automatically.

Would this be easier?: Launch the Access FORM and read in the data from
the

[quoted text clipped - 7 lines]

Is it possible? or are the Access Designers missing something

 

[Douglas J. Steele]

I fear you read far more into my comments than was intended.

--
Doug Steele, Microsoft Access MVP

(no e-mails, please!)

1) When you say "You cannot EXPORT a Form", this is not true. You can
export
the table connected to the Form but you are not EXPORTING the table
directly.
If you look into EXPORT from the Form (Right CLICK the Form and select
EXPORT)
it will allow you to export BACK to the original External Text File.
Unfortunately (if you look into this yourself) when you EXPORT through the
Form it produces a Text File which is Formatted and it fills the Text File
with Stupid Dashes.

Where did I say you cannot export a form? The closest I can see is "Forms
don't have data: tables do. Using TransferText to export the data from the
tables doesn't limit you to formatted text files with dashes added."

2) You stated..."You could link to the text files", again this is not
possible because Access clearly states that 'Linked Files CANNOT be edited
and can ONLY be appended too". As the User wishes to edit the original
Text
Files using your suggested method will not work.

You can link to text files. Linking does NOT necessarily mean updating. Note
that my comment said "You could link to the text files, and use the linked
tables as the basis for queries that refreshes the data in your Access
tables."

3) You stated "Text files don't allow multiple users to update them.
Because
of that
limitation, there's no way for Access to update linked text files" If you
had
read my post before commenting, you would have seen that I clearly stated
that..."The RTSD will not be adding records to the Text Files while the
user
is editing the files, so there is no conflict". This makes your comment
unnecessary

My comment has nothing to do with YOUR data source. It is a generic comment
about Windows. It's not possible for multiple users to update a text file.
Because of that, Access does not provide the ability to update a text file.
I suspect that this is because Access is intended to be a multiuser
application and the developers didn't want things to work inconsistently.

I am using a Form because the USER wishes to process data from External
Text
FIles (single user, nobody else messing with the files, files are static,
there are no networks involved and there is only one computer and one
person).
In order for the User to edit the information once it has been obtained, I
am
using FORMS...is this not the purpose of a Form?

Yes, Forms are windows into the data contained in tables. To change data,
you use a form.

Once the USer is happy with the results, he/she will wish to print the
results to paper. I have two Forms, the first is a SIngle Computation
directly to the Form and I have placed a Print Form command button on the
Form for this purpose. All works well on the Single Computation Form.

The second Form is a little more complex as it is a Nested version of the
First Form. Each time the the Form processes information, I would like the
resulting Form to automatically print. Then the Form will automatically
generate the next set of data and the process will repeat. Unfortunatly,
the
only command I can find is: RunCommand(acCmdPrint). This command invokes
the
Print Dialog Box which forces the User to click PRINT each time the Form
recalculates.

There are NO references in any book, the Microsoft resourses on the Web
that
indicate how data from a Form can be SAVED to a Report. I have heard that
it
is possible to save a Form as a Report but I have no idea how and cannot
find
any references as to how it is done.

In Access 2003 and earlier, you select the form in the database window and
right-click. One of the options in the context-sensitive menu that appears
is "Save as report". I'm afraid I don't have Access 2007 installed on this
machine, so I'm not positive of the sequence there.

When you examine the differences between Forms and Reports, the only real
difference is that a Form is more versatile. If Microsoft were to include
the
same Printing and Formatting functionality in a Form as there is in a
Report,
there would be no need to even have Reports.

Is there a better way?

Now, this is a comment to all who respond to these posts:
1) If a Poster posts information regarding a method of working Access is
is
because things are not working as expected or desired.

2) If the comments come back as..."Why are you doing it that
way"..."Access
provides a much better solution"..."I dont undestand why anybody would do
it
that way"...Remember this, if there IS a better way, but we have not used
it
it is because..."we did not know there was a better way, otherwise we
would
have used it". So, please refraim from "Bombastigating" us and choose a
milder more constructive approach such as..."Although it is possible to do
it
that way, my experience has tough me that this approach would yield better
results as follows", here you would provide either a LINK or a Code
Fragment
to illustrate...THE BETTER WAY...Just a thought.

Comments in-line.

Either "I" lack of understanding of Access or the Access designers have
a
lack of understanding of User erquirements. I need to know if I
understand

[quoted text clipped - 12 lines]

you
cannot edit external data with a LINKED Table.

Text files don't allow multiple users to update them. Because of that
limitation, there's no way for Access to update linked text files.

Forms:_ For my application, these Forms allow me to alter the data in
the
Tables. I can PRINT the Forms after the Forms have processed the data in
the
Tables even though purists decry this activity as Reports are
favoured...all
correct?

While it's possible to print forms, why would you? You don't have much
control over how they print. As well, you lose the ability to include
grouping.

Well, I have a problem with this set-up and here is why:
EVERYTHING goes back to the original Text FIles which are the key to

[quoted text clipped - 4 lines]

needs to re-read the text files back-in each time the Access Database is
launched.

You could link to the text files, and use the linked tables as the basis
for
queries that refreshes the data in your Access tables. If you look at my
November, 2003 "Access Answers" column in Pinnacle Publication's "Smart
Access", you'll see how you can append new records and change existing
records with a single query. (You can download the column and sample
database for free at http://www.accessmvp.com/DJSteele/SmartAccess.html)

If the USER uses the Forms to edit/add/delete data from the tables, the
USER

[quoted text clipped - 4 lines]

TEXT
FILES with all the extra "Dashes" added.

I don't understand this statement.

Forms don't have data: tables do. Using TransferText to export the data
from
the tables doesn't limit you to formatted text files with dashes added.

So here is what the User has to do now:
1) Run Access and IMPORT the external Text Files into the Tables. As
there
are Eleven (11) Text Files they all have to be done seperatly.

Hopefully you're not making the user import 11 times: that you're
automating
the process for him/her!

2) Launch the relavent Forms and process the data back to the Tables.

[quoted text clipped - 4 lines]

in
the External Data being changed while Access is operating on the data.

Again, hopefully you've automated the process so that the user only has to
push a single button and all of the exports are done automatically.

Would this be easier?: Launch the Access FORM and read in the data from
the

[quoted text clipped - 7 lines]

Is it possible? or are the Access Designers missing something

 

[Cipher via AccessMonster.com]

I am using 2007 and there is NO sequence

I fear you read far more into my comments than was intended.

1) When you say "You cannot EXPORT a Form", this is not true. You can
export

[quoted text clipped - 6 lines]

Form it produces a Text File which is Formatted and it fills the Text File
with Stupid Dashes.

Where did I say you cannot export a form? The closest I can see is "Forms
don't have data: tables do. Using TransferText to export the data from the
tables doesn't limit you to formatted text files with dashes added."

2) You stated..."You could link to the text files", again this is not
possible because Access clearly states that 'Linked Files CANNOT be edited
and can ONLY be appended too". As the User wishes to edit the original
Text
Files using your suggested method will not work.

You can link to text files. Linking does NOT necessarily mean updating. Note
that my comment said "You could link to the text files, and use the linked
tables as the basis for queries that refreshes the data in your Access
tables."

3) You stated "Text files don't allow multiple users to update them.
Because

[quoted text clipped - 6 lines]

is editing the files, so there is no conflict". This makes your comment
unnecessary

My comment has nothing to do with YOUR data source. It is a generic comment
about Windows. It's not possible for multiple users to update a text file.
Because of that, Access does not provide the ability to update a text file.
I suspect that this is because Access is intended to be a multiuser
application and the developers didn't want things to work inconsistently.

I am using a Form because the USER wishes to process data from External
Text

[quoted text clipped - 4 lines]

am
using FORMS...is this not the purpose of a Form?

Yes, Forms are windows into the data contained in tables. To change data,
you use a form.

Once the USer is happy with the results, he/she will wish to print the
results to paper. I have two Forms, the first is a SIngle Computation

[quoted text clipped - 18 lines]

find
any references as to how it is done.

In Access 2003 and earlier, you select the form in the database window and
right-click. One of the options in the context-sensitive menu that appears
is "Save as report". I'm afraid I don't have Access 2007 installed on this
machine, so I'm not positive of the sequence there.

When you examine the differences between Forms and Reports, the only real
difference is that a Form is more versatile. If Microsoft were to include

[quoted text clipped - 100 lines]

 

[Douglas J. Steele]

I have no idea what you mean by "there is NO sequence"

--
Doug Steele, Microsoft Access MVP

(no private e-mails, please)

I am using 2007 and there is NO sequence

I fear you read far more into my comments than was intended.

1) When you say "You cannot EXPORT a Form", this is not true. You can
export

[quoted text clipped - 6 lines]

Form it produces a Text File which is Formatted and it fills the Text
File
with Stupid Dashes.

Where did I say you cannot export a form? The closest I can see is "Forms
don't have data: tables do. Using TransferText to export the data from the
tables doesn't limit you to formatted text files with dashes added."

2) You stated..."You could link to the text files", again this is not
possible because Access clearly states that 'Linked Files CANNOT be
edited
and can ONLY be appended too". As the User wishes to edit the original
Text
Files using your suggested method will not work.

You can link to text files. Linking does NOT necessarily mean updating.
Note
that my comment said "You could link to the text files, and use the linked
tables as the basis for queries that refreshes the data in your Access
tables."

3) You stated "Text files don't allow multiple users to update them.
Because

[quoted text clipped - 6 lines]

is editing the files, so there is no conflict". This makes your comment
unnecessary

My comment has nothing to do with YOUR data source. It is a generic
comment
about Windows. It's not possible for multiple users to update a text file.
Because of that, Access does not provide the ability to update a text
file.
I suspect that this is because Access is intended to be a multiuser
application and the developers didn't want things to work inconsistently.

I am using a Form because the USER wishes to process data from External
Text

[quoted text clipped - 4 lines]

am
using FORMS...is this not the purpose of a Form?

Yes, Forms are windows into the data contained in tables. To change data,
you use a form.

Once the USer is happy with the results, he/she will wish to print the
results to paper. I have two Forms, the first is a SIngle Computation

[quoted text clipped - 18 lines]

find
any references as to how it is done.

In Access 2003 and earlier, you select the form in the database window and
right-click. One of the options in the context-sensitive menu that appears
is "Save as report". I'm afraid I don't have Access 2007 installed on
this
machine, so I'm not positive of the sequence there.

When you examine the differences between Forms and Reports, the only
real
difference is that a Form is more versatile. If Microsoft were to
include

[quoted text clipped - 100 lines]

Is it possible? or are the Access Designers missing something