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

Our current app replicated back end is a bit bloated.  My idea is to 
 
unreplicate it using an utility and then import all into a new db.  After 
 
unreplicating, is it better to... 
 
1.  In a new db, create empty tables that matching old table formatting, and 
 
then somehow pull the content from old tables to equivalent new tables. 
 
or 
 
2.  Just import entire tables as they are.  (I tried a test of this and the 
 
bloat was reduced 90%).  I'm more worried about integrity. 
 
Nick

Well that was helpful.  Thanks.  I can say that we always compact and repair 
 
andI never relocate replicated dbs.  There are instances when a replica 
 
cannot be accessed during a sync attempt due to network problems.  What is 
 
the procedure to follow when this happens?  The app always returns a message 
 
that the replica was deleted from the set. 
 
Is there a problem synching from the replica when the master is open?  It 
 
seems to work well though it takes longer. 
 
Can the msysTomstones and Conflict tables (assuming conflicts are resolved) 
 
be safely deleted? 
 
Thanks again. 
 
"jacksonmacd" <jackMACmacdo0nald@telus.net> wrote in message 
 
news:vkhed2h30ui1gqhh8dn11s2s6vo8jair61@4ax.com...

If it was me, I would look at finding the source of the 'bloat' before 
 
I went to the trouble of doing the steps you described. A BE database 
 
is not subject to the same bloating pressures that a development FE 
 
is. Some things to consider: 
 
Each replica can be compacted, just like a conventional database. Have 
 
you done that yet? 
 
One consumer of space in a replicated database is the hidden 
 
msysTombstones table where Jet stores information about deleted 
 
records until that information is passed to all replicas in the set. 
 
If your replica set contains 'dead' replicas, then the Tombstones 
 
table will hold the info until the Retention Period has expired. This 
 
period defaults to 1000 days. 
 
Dead replicas result from poor practices such as copying a replica and 
 
opening it from several locations. Are you currently doing anything 
 
that can result in dead replicas? If you *are*, then your efforts 
 
about creating a new replica set will be in vain. 
 
As for your original question, it's probably six of one, a half dozen 
 
of the other... The only utility that I am aware of to unreplicate a 
 
database does so by creating a new copy of the database and running 
 
Append queries to copy the data. Making a new copy of *that* database 
 
is probably a moot point. 
 
What is sometimes recommended to re-build a corrupted replica set is 
 
to create empty tables in a new MDB and use queries to move the data. 
 
In this situation, you *cannot* import the tables directly because 
 
they carry the hidden replication information. 
 
On Sun, 6 Aug 2006 23:34:34 -0500, "Nick" <nickmirro@spamarrest.com> 
 
wrote: 
 
-- 
 
jackmacMACdonald@telusTELUS.net 
 
remove uppercase letters for true email 
 
http://www.geocities.com/jacksonmacd/ for info on MS Access security

"Nick" <nickmirro@spamarrest.com> wrote in 
 
news:eb34IrduGHA.3964@TK2MSFTNGP04.phx.gbl: 
 
I don't see that it makes any difference. 
 
Did the bloat not disappear after a compact? 
 
-- 
 
David W. Fenton                  http://www.dfenton.com/ 
 
usenet at dfenton dot com    http://www.dfenton.com/DFA/

jacksonmacd <jackMACmacdo0nald@telus.net> wrote in 
 
news:vkhed2h30ui1gqhh8dn11s2s6vo8jair61@4ax.com: 
 
The Microsoft and Michael Kaplan utilities change the original 
 
replica, not making a copy. 
 
-- 
 
David W. Fenton                  http://www.dfenton.com/ 
 
usenet at dfenton dot com    http://www.dfenton.com/DFA/

"Nick" <nickmirro@spamarrest.com> wrote in 
 
news:e$oESUjuGHA.4872@TK2MSFTNGP02.phx.gbl: 
 
Not an issue. All you have to do is attempt a synch when the 
 
connection  is present, and it will work. The replica won't be in 
 
the dropdown list, but you can use the BROWSE button to point at it. 
 
The design master? Are you using the DM for regular work? You 
 
shouldn't. The DM should not be used for daily editing/synching. It 
 
should be preserved and used only for implementing design changes. 
 
It should be synched occasionally just to keep it from expiring, but 
 
otherwise, it should not be in use. 
 
As to synchs when the synched replica is in use, this can result in 
 
two problems (at least): 
 
1. if the user is editing a memo field in a bound form when the 
 
replica is synched, the memo can be corrupted, and this can result 
 
in the loss of the entire record. Solution: don't synch when editing 
 
*or* edit all memo fields in unbound textboxes. 
 
2. if a design change is included in a synch and someone has the 
 
table open with the design change, the design change will fail (for 
 
obvious reasons). However, this causes no long-term problems, as the 
 
design change will propagate the first time Jet can get an exclusive 
 
lock on the table. 
 
-- 
 
David W. Fenton                  http://www.dfenton.com/ 
 
usenet at dfenton dot com    http://www.dfenton.com/DFA/

Thanks for your answers. 
 
Compacting does not affect the increasing size of the backend, though it did 
 
help to slow it. 
 
Can the msysTomstones and Conflict tables (assuming conflicts are 
 
resolved) be safely deleted? 
 
Nick 
 
"David W. Fenton" <XXXusenet@dfenton.com.invalid> wrote in message 
 
news:Xns9818A503996A2f99a49ed1d0c49c5bbb2@127.0.0.1...

"Nick" <nickmirro@spamarrest.com> wrote in 
 
news:eWfZy#nuGHA.2148@TK2MSFTNGP02.phx.gbl: 
 
The tombstones table cannot be deleted. Conflict tables can be, but 
 
they shouldn't be -- you should resolve the conflicts, and once 
 
those are resolved, those tables will disappear. If they are empty, 
 
they should have been deleted already. 
 
If your app is designed to frequently delete records, then it's got 
 
a problem. Replicated apps don't work well with deleted records. If 
 
you have a temp table, for instance, that you're appending data to 
 
temporarily and then deleting, that table should not be replicated 
 
at all. 
 
-- 
 
David W. Fenton                  http://www.dfenton.com/ 
 
usenet at dfenton dot com    http://www.dfenton.com/DFA/

As answered elsewhere, the tombstones table cannot be deleted. 
 
However, it can be viewed -- does it contain *many* records after a 
 
"full replica set" synchronization. IOW, if you've sync'd with all the 
 
replicas in the set (and possibly multiple times to ensure full 
 
communication in both directions), and the Tombstones table continues 
 
to contain records, I believe that's a sign that your replica set 
 
contains one or more dead replicas. That could be the source of your 
 
problems. 
 
On Mon, 7 Aug 2006 19:15:04 -0500, "Nick" <nickmirro@spamarrest.com> 
 
wrote: 
 
-- 
 
jackmacMACdonald@telusTELUS.net 
 
remove uppercase letters for true email 
 
http://www.geocities.com/jacksonmacd/ for info on MS Access security

On Mon, 07 Aug 2006 15:14:26 -0500, "David W. Fenton" 
 
<XXXusenet@dfenton.com.invalid> wrote: 
 
I stand corrected. 
 
-- 
 
jackmacMACdonald@telusTELUS.net 
 
remove uppercase letters for true email 
 
http://www.geocities.com/jacksonmacd/ for info on MS Access security

jacksonmacd <jackMACmacdo0nald@telus.net> wrote in 
 
news:ofvfd2pvasbt8cgmpk6culh8smvslec7v6@4ax.com: 
 
I've never known dead replicas to increase the size of the 
 
tombstones table. I can't see any way how dead replicas would 
 
increase the number of records in the tombstones table at all. 
 
-- 
 
David W. Fenton                  http://www.dfenton.com/ 
 
usenet at dfenton dot com    http://www.dfenton.com/DFA/

There is a make-table query that produces a repeatedly overwritten table. 
 
It doesn't need to be replicated so I will change it.  I will have our 
 
developer look at this thread and review the back end design.  Thanks again. 
 
Nick 
 
"David W. Fenton" <XXXusenet@dfenton.com.invalid> wrote in message 
 
news:Xns9818CFBE55FEFf99a49ed1d0c49c5bbb2@127.0.0.1...

"Nick Mirro" <nmirro@ticnet.com> wrote in 
 
news:uK#3PRyuGHA.1296@TK2MSFTNGP02.phx.gbl: 
 
That shouldn't be in the back end. 
 
It shouldn't be in the front end, either. 
 
Create a temp.mdb for that purpose so you don't have to have it in 
 
an MDB that is persistent. And don't use a maketable, but instead 
 
append the records to an existing table, and delete them before the 
 
append or after you're done with them. 
 
-- 
 
David W. Fenton                  http://www.dfenton.com/ 
 
usenet at dfenton dot com    http://www.dfenton.com/DFA/