Re: Forms or Reports

Tech-Archive recommends: Fix windows errors by optimizing your registry

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

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no e-mails, please!)


"Cipher via AccessMonster.com" <u47407@uwe> wrote in message
news:8db8b75d81186@xxxxxx
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.

Douglas J. Steele wrote:
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

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-forms/200811/1



.

Quantcast