ASP.NET, SQL Server, WPF, C#, VB.NET

I've got an Access 2000 format database that has been working well for 
 
several years. It's been replicated to two other users. Today I tried to 
 
synchronize the Master to one Replica and got this message: 
 
"The search key was not found in any record." 
 
Supposedly, this is error 3709. When I looked it up in MSKB, it said it 
 
maybe caused by an indexed Memo field. However, that's not the case. 
 
I am using MS Access 2003. Any ideas to get it to sync again? 
 
-- 
 
... jim ..

JimEagleOne <Ectype77NOSPAM@aol.com> wrote in 
 
news:08EDF3CA-C1B0-44C7-A77F-97DBDA5C0B9F@microsoft.com: 
 
First off, is the database split, with forms and reports in one MDB 
 
(NOT REPLICATED) and the data tables in another replicated MDB? If 
 
not, that's where you should start, by getting rid of the 
 
forms/reports, because trying to replicate those is the most common 
 
source of replication failures. 
 
I've never experienced it any sitatuion that the KB suggestion was 
 
correct. My experience has been that it has 3 causes: 
 
1. damaged LDB file. Try deleting the LDB and see if that helps. 
 
2. corruption. Can usually be cleared with a compact (make a backup 
 
copy first). 
 
3. mis-matched workgroup file. If the app is unsecured, be sure to 
 
use a default system.mdw, as a custom one can cause this error. 
 
You have to fix the corruption. 
 
I'm not sure if you can, though. I've never run into this problem in 
 
a replicated database. But I've also never run into it that it 
 
wasn't anything more than just a transient error. 
 
-- 
 
David W. Fenton                  http://www.dfenton.com/ 
 
usenet at dfenton dot com    http://www.dfenton.com/DFA/

JimEagleOne <Ectype77NOSPAM@aol.com> wrote in 
 
news:0DA090AA-C6DA-492E-8494-9465733B15DD@microsoft.com: 
 
I can't offer any further advice until you split the database. So 
 
far as I can tell, that's likely to be the only remaining cause of 
 
the failure. 
 
-- 
 
David W. Fenton                  http://www.dfenton.com/ 
 
usenet at dfenton dot com    http://www.dfenton.com/DFA/

JimEagleOne <Ectype77NOSPAM@aol.com> wrote in 
 
news:D7AB983A-B812-46CA-A2B9-C8070DC94EB3@microsoft.com: 
 
Open your design master. 
 
Unreplicate all the forms, and reports and code and macros. 
 
Import everything but the tables into a new MDB. 
 
In the new MDB, create links to the tables in the back end. 
 
Then delete everything from the design master that is not 
 
replicated. 
 
This is the absolute standard way for distributing Access apps, and 
 
has been since forever (I've been developing in Access 
 
professionally since 1996), and is the only way replication works -- 
 
replication is a Jet technology and works well (despite MS's claims 
 
to the contrary) only with pure-Jet objects. That means tables and 
 
queries. Everything else is not replicable in any practical sense, 
 
and there is not real justification for it being replicable, since 
 
design changes are only ever one-way, and never two-way. 
 
-- 
 
David W. Fenton                  http://www.dfenton.com/ 
 
usenet at dfenton dot com    http://www.dfenton.com/DFA/

JimEagleOne <Ectype77NOSPAM@aol.com> wrote in 
 
news:560F106D-C176-444B-9BFB-9F896DB1308D@microsoft.com: 
 
Well, first off, I've never replicated a form in my life, in any 
 
version of Access, because I understand how replication works, and 
 
knew from the beginning that there was no reason to ever replicate 
 
anything but tables. 
 
But, to be helpful, I converted an A2K MDB to a replica, and found 
 
that, yes, there is no Replicable property. However, if you import 
 
the replicated form into a non-replicated MDB, it is not replicable 
 
in the new MDB. So, it's pretty simple -- just import all your 
 
non-table objects (including queries) into your new front end MDB, 
 
and you'll be fine. 
 
Access 2K can't do it, either. 
 
And I never knew this, as it's something I'd never encounter, since 
 
I would never even imagine replicating forms, etc. 
 
Well, you change the DM and then synch with the problematic MDB. 
 
That will delete the non-table objects and then maybe the problem 
 
will go away. 
 
Of course, if you can't synch at all, then this particular replica 
 
is hosed from the standpoint of synchronization. 
 
That's an expected eventuality when you replicate non-Jet objects. 
 
It's unfortunate that the MS replication documentation still doesn't 
 
make this fact clear. 
 
-- 
 
David W. Fenton                  http://www.dfenton.com/ 
 
usenet at dfenton dot com    http://www.dfenton.com/DFA/