Re: Error 3155- Is there no solution?

I don't know, sorry.
--
Dave Hargis, Microsoft Access MVP


"Mark A. Sam" wrote:


"Klatuu" <Klatuu@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E5BDB9EC-1FA7-4745-8556-108C02C8F6D5@xxxxxxxxxxxxxxxx
Are there any contstraints on the fields in the offending table?

No.

If, for
example, you have a foreign key field in your table and no value is being
assigned to it, you will get such an error.

The only key is an Idenity column, but I doubt that is the problem. I use
the dbSeeChanges option when setting the recordset variable. This problem
only occurs when an order (the main Table) is created and products entered
immeditely aferward. But that isn't always true according ot the users. If
I open the form to an existing record, enter products, then populate
materials and tasks, the procedure will work fine.

This may have something to do with Identify Insert being turned on. In my
code I remmed out lines which assigned values to the Identity column.
Apparently that was working but caused problems when adding records through
the form. How can to turn the Identity column off?


--
Dave Hargis, Microsoft Access MVP


"Mark A. Sam" wrote:


"gllincoln" <gllincoln@xxxxxxxx> wrote in message
news:89F7CEE8-F035-4C55-8F23-7CC8B4132DA0@xxxxxxxxxxxxxxxx
Hi Mark,

Do the users each have their own copy of the front end, including the
remote terminal services users?

* Yes it is uploaded to their local drive when they log on.

Concurrent use of a copy of a front end application can create many
severe side-effects.

*I agree.

What you describe sounds like an issue of a table time out, good chance
of that being due to the table being locked.

*I really don't believe either is the case, becuase it only occurs with
the one table. Also becuase this is a common error. I have searched it
on google and read through many of the threads without see a solution.

You might want to look at all processes that use the Materials table -
anything that sets an exclusive lock on a larger scale than a current
record level.

*I wouldn't know how to investigate that. Since the process is adding
records, I don't know how this could be a record locking issue.

It doesn't have to be anything related to order entry, could be some
inventory evaluation or demand estimating work*** run by somebody in
purchasing via an Excel workbook (just an example).

*I have thought of that. The data is taken from default records, but
they are rarely updated and not usualy that anyone accesses them. This
is a constant occurance. This weekend I was the only person on the
system late night Saturday.

Whatever is creating the conflict is most likely locking the table to
read only, until it its procedure is complete.It's the intermittent
nature of the problem description that suggests to me that an external
and unrelated event locking the table is a strong possibility.

*I don't see how. It the table is being locked, I would think that is
a problem. How could anyone use SQL Server in a useful way if tables
lock up whenever data is being added.

If this is a typical order entry process - it's relatively mission
critical that the data be preserved but one can wait at least a short
while to updata the back end table.

*I can't do that. reports are printed and emailed right after the order
is added. It would be a nuisense to delay the reports.

You might create a temp incoming order copy of the materials table,
then set a process to append the contents of that table to the main
backend table on a set interval. The user could go on their way, you
would have the data and could (worst case scenario) run a SQL query at
the end of the day to append any records that weren't already in the main
system and clean out the temp table for the next day use. This timeline
may not work in your situation - but there is probably some variation of
this concept that could work for you.

*Good thought, but I can't do that. Many of the orders need to be
processed and shipped that day.

This is a brute force solution but I get the impression you have been
working on this one for a while - a work-around lets the users be about
their work and buys you time for unhurried and more deliberate
investigation.

*A long while. 4 or 5 years ago I converted the back end from Access
to SQL Server. That opened a huge can of worms. I worked out all of the
problems except this. I hadn't done any work for this client for a year
and a half and thought it was resolved. It hadn't been and I need to get
it done. I am going to try an append query. Thanks for your input and
God Bless,


Hope this helps..



.