Access 2K2 Form Updates

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I am working on an Access 2K2 Database that will assist the temps in my
office audit our firms files. Information from these files are stored on a
server in SQL tables with read only access. What I would like to do is be
able to have the temps open the audit form and have the customer information
prefill from the server, as opposed to having the temps retype customer info
for each and every file that they audit. The info from the read only tables
and the auditors findings should be able to store for later reporting
processes post audit. Is there a way to do this? Thanks.
 
I am working on an Access 2K2 Database that will assist the temps in my
office audit our firms files. Information from these files are stored on a
server in SQL tables with read only access. What I would like to do is be
able to have the temps open the audit form and have the customer information
prefill from the server, as opposed to having the temps retype customer info
for each and every file that they audit. The info from the read only tables
and the auditors findings should be able to store for later reporting
processes post audit. Is there a way to do this? Thanks.
Click to expand...

I'm not sure I understand.

You want to store data in read-only tables? Obviously, you can't. Or
do you want to store the customer information redundantly in a second
table? You *can* but you probably shouldn't - imagine the auditing
nightmare if the temp pulls up a record, stores it, and three minutes
later somebody on another computer enters a name spelling error
correction into the SQL table.

I agree, the user should NOT be retyping customer information - my
question is why it's necessary to store this information redundantly
at all! Maybe it is; but before leading you down the wrong path I'd
like to clarify why! If you simply store the unique customerID, you
should be able to generate a Report by joining the audit table to the
SQL table to pick up the customer information.

John W. Vinson[MVP]
 
The only reason to hold onto the information is for reporting purposes. The
accounts that are being audited are accounts that were generated within the
previous month. for example, January's assignment is to audit new accounts
opened in Dec 2004. If there were mistakes made, then reports are generated
using the information from the temps as well as the account information
stored on the servers. February's assignment will be to audit January
accounts and so forth. there are different criteria for each temp to pull in
auditing the accounts (ex: one temp might look for all accounts >5K opened in
12/04, another might audit all accounts opened within a particular region of
the country, etc) findings would be stored and reports created from that
information.
 
The only reason to hold onto the information is for reporting purposes. The
accounts that are being audited are accounts that were generated within the
previous month. for example, January's assignment is to audit new accounts
opened in Dec 2004. If there were mistakes made, then reports are generated
using the information from the temps as well as the account information
stored on the servers. February's assignment will be to audit January
accounts and so forth. there are different criteria for each temp to pull in
auditing the accounts (ex: one temp might look for all accounts >5K opened in
12/04, another might audit all accounts opened within a particular region of
the country, etc) findings would be stored and reports created from that
information.
Click to expand...

Ok; that's all well and good.

But I don't see any reason why that justifies storing data
redundantly. Queries against your SQL tables can generate all these
reports without that overhead!

If you really want to do so, I'd use Append queries to make local
Access table copies of the relevant subsets of the SQL tables.

John W. Vinson[MVP]
 
Back
Top