Error 3014 and 3518

[Suse Baeriswyl]

Hi,

1. Does anybody know, how to handle the error massage 3114 in Access
2003 with Jet4.0, Version 4.0.8618.0?

According to http://www.mvps.org/access/bugs/bugs0010.htm the jet-engine
3.5 can be updated to avoid the error. But what to do in 4.0?

2. What can I do with error 3518:"systemtab le tombstone cannot be opened
because it es allready in use".

How far is the grave of this replicated database? Before the replication
it worked fine.

Thanks so much for help

Suse Baeriswyl from Berne, Switzerland
------------ And now a word from our sponsor ----------------------
For a quality mail server, try SurgeMail, easy to install,
fast, efficient and reliable. Run a million users on a standard
PC running NT or Unix without running out of power, use the best!
---- See http://netwinsite.com/sponsor/sponsor_surgemail.htm ----

[David W. Fenton]

Suse Baeriswyl <su************ @hist.unibe.ch> wrote in
news:42******** @news.unibe.ch:

1. Does anybody know, how to handle the error massage 3114 in
Access 2003 with Jet4.0, Version 4.0.8618.0?

According to http://www.mvps.org/access/bugs/bugs0010.htm the
jet-engine 3.5 can be updated to avoid the error. But what to do
in 4.0?
Well, if you're running out of table handles, the base solution is
to redesign your application to open fewer recordsets at a time.
This means fewer forms open at once and simpler recordsources (less
use of nested queries, for instance).

It also means populating the recordsources and rowsources for only
the visible subforms and combo/listboxes.
2. What can I do with error 3518:"systemtab le tombstone cannot be
opened because it es allready in use".

How far is the grave of this replicated database? Before the
replication it worked fine

I assume you've compacted the database? Perhaps you have an
undeleted LDB file that is preventing you from getting a lock on
MSysTombstones, so you might want to check if the LDB file is still
there when there is no one with the replica open. Sometimes your
server could maintain file system user locks even after a user has
logged off. Having the offending user log off and log back on will
often release the locks. If that fails, you can use the Control
Panel administrative tools to force close the connection to the
file, and then you should be able to get rid of the LDB.

And I assume that you have data in this replica that hasn't been
synched with another database? If you don't have any non-synched
data, then just trash the replica and create a replacement.

This is the reason for the concept of "replica farms," where instead
of having a single replica at each site, you have a group of
replicas that are constantly synched with each other and only one of
them is edited by users. If that one becomes corrupted or unusable
for some reason, all (or nearly all) of the data will be in one of
the other replicas, so you can just kill the bad replica, attempt a
synch with it from the other replicas in your replica farm (which
clears it from the list of replicas in the replica set) and then
create a new replica to replace it.

The tombstone table, as you probably know, is used to track record
deletions. If it gets very large, you're probably deleting too much
data, and should revisit your replication design (it's probably
better in that case to mark records deleted and hide them from
users).

Also, the tombstone table's size is going to be impacted by your
replica set's retention period. If you don't set that, the value is
1000 days (the default). You can set it to something smaller in the
Design Master, synch with the replicas, and it can significantly
reduce the size of the tombstone table and the replication history
table.

But I doubt it would solve the problem you're having.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc