467,219 Members | 1,479 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,219 developers. It's quick & easy.

"Accumulator" table for multiple computers WITHOUT concurrencyproblems

Hi. I have an Access application which does lots of things by going
through some PINS in some large tables.
This application is installed on multiple computers, and works fine,
with one exception:
For reporting purposes, I need to keep a "central" table where each
application would save some data.
Currently I'm using a LINKED excel file named "SharedAccumulator" and
after each PIN successfully processed a record is added in the
"SharedAccumulator" table.

I'm experiencing occasional error 3343 (as in http://support.microsoft.com/kb/q238401/)
and 3734 (as in http://support.microsoft.com/kb/274211). I am using
Access 2000 and Excel 2000.

What could I do ? Use another approach, maybe ? Would saving to a
SQLServer db help (by using some stored procedures, maybe, with many-
many params (since my accumulator table has many-many fields).

Thank you very much.
Alex
Jul 27 '08 #1
  • viewed: 1858
Share:
2 Replies
On Sun, 27 Jul 2008 16:53:26 -0700 (PDT), Radu
<cu*************@yahoo.comwrote:

Excel is a poor choice because it is not great with locking
strategies. Why not use an Access table? You are already using Access
anyway.
When adding (or updating, for that matter) a record in a multi-user
environment there always is a chance of a write conflict. That is
normal. You should be able to deal with that with a good error
handler. For example one that in a loop silently goes to sleep for an
increasing amount of time and retries (using Resume), until successful
or a set amount of time is expired. Only then would the user get the
error message.

-Tom.
Microsoft Access MVP
>Hi. I have an Access application which does lots of things by going
through some PINS in some large tables.
This application is installed on multiple computers, and works fine,
with one exception:
For reporting purposes, I need to keep a "central" table where each
application would save some data.
Currently I'm using a LINKED excel file named "SharedAccumulator" and
after each PIN successfully processed a record is added in the
"SharedAccumulator" table.

I'm experiencing occasional error 3343 (as in http://support.microsoft.com/kb/q238401/)
and 3734 (as in http://support.microsoft.com/kb/274211). I am using
Access 2000 and Excel 2000.

What could I do ? Use another approach, maybe ? Would saving to a
SQLServer db help (by using some stored procedures, maybe, with many-
many params (since my accumulator table has many-many fields).

Thank you very much.
Alex
Jul 28 '08 #2
What are "PINS"?

Thanks,

Steve

"Radu" <cu*************@yahoo.comwrote in message
news:ab**********************************@d77g2000 hsb.googlegroups.com...
Hi. I have an Access application which does lots of things by going
through some PINS in some large tables.
This application is installed on multiple computers, and works fine,
with one exception:
For reporting purposes, I need to keep a "central" table where each
application would save some data.
Currently I'm using a LINKED excel file named "SharedAccumulator" and
after each PIN successfully processed a record is added in the
"SharedAccumulator" table.

I'm experiencing occasional error 3343 (as in
http://support.microsoft.com/kb/q238401/)
and 3734 (as in http://support.microsoft.com/kb/274211). I am using
Access 2000 and Excel 2000.

What could I do ? Use another approach, maybe ? Would saving to a
SQLServer db help (by using some stored procedures, maybe, with many-
many params (since my accumulator table has many-many fields).

Thank you very much.
Alex

Jul 28 '08 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

15 posts views Thread by Jordan Rastrick | last post: by
12 posts views Thread by Georg Brandl | last post: by
11 posts views Thread by L. Chen | last post: by
21 posts views Thread by Helge Jensen | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.