Question Compact & Repair Log Message

[Buj]

Hi, I have a replica set of the back end of a split mdb which is in 2002/3 format.

I've just run my first synch on live data and got some conflicts which were all in the table MSysAccessStorage. Having googled around a bit, I'm assuming this is because I have one form in my backend (therefore being replicated). The reason I have a form in the backend is because I wanted to password protect the backend, and as far as I can see, Access won't allow replication on a database which is password protected using the usual means, and once an unprotected db has been replicated, you can't set the db password on the master or replicants either. So I built in a form to handle that, and in hindsight I guess that's what's causing the MSysAccessStorage problem (since the form also requires macros and a module associated with it, and I gather now that replicating forms and other front-end type objects should be avoided).

The front end of the database is also coded to run a compact and repair on the backend when the front end is closed (via a command button). Since synching with the MSysAccessStorage conflicts (which I just 'resolved' by accepting the winner in each case), this compact and repair function gives a log file with this text: "Modules Container: 'DirDataCopy' stream has a length of zero!"

First question... is there any way to password protect such a backend without using forms and such? The driver for this is that users with a little bit of knowledge have been known, in the past, to add their own values to reference tables - values that the organisation doesn't want to use.

Second question... given that this is live data, what's the best way to get the synched data into good shape (i.e. without whatever issues the MSysAccessStorage / DirDataCopy problems are causing/stemming from) - do I just import the whole thing (presumably minus the offending front-end-type objects in the back end) into a new database and create new replicas?

Third question... what does the log file error actually mean?? Or would explaining it make my brain explode?!

Any help much appreciated.

Cheers,
Buj.

 

[dfenton]

First question... is there any way to password protect such a backend without using forms and such? The driver for this is that users with a little bit of knowledge have been known, in the past, to add their own values to reference tables - values that the organisation doesn't want to use.

You could certainly implement Jet user-level security. But you might not want to go that far, as it will also affect the front end.

You might want to read my post in this thread at StackOverflow.com:

http://stackoverflow.com/questions/...er-rights-to-an-access-database/530778#530778

You can keep out most of the curious simply by turning off AllowBypassKey and adding an AutoExec macro that exits Access when run. Sure, for your own purposes, you'd have to turn AllowBypassKey back on to work in the back end, but, how often do you do that?

Second question... given that this is live data, what's the best way to get the synched data into good shape (i.e. without whatever issues the MSysAccessStorage / DirDataCopy problems are causing/stemming from) - do I just import the whole thing (presumably minus the offending front-end-type objects in the back end) into a new database and create new replicas?

Likely if you delete the offending form, the problem will go away. But if it doesn't, you probably will find it easier to use the unreplicate tools listed in the Jet Replication Wiki FAQ at question 10:

http://dfenton.com/DFA/Replication/index.php?title=FAQ

Third question... what does the log file error actually mean?? Or would explaining it make my brain explode?!

I don't know what the log file error means. I've never had a replica with a form in it, so never encountered any such problems.

Any help much appreciated.

Cheers,
Buj.[/QUOTE]

 

[Buj]

Thanks very much, David. I'll check those resources out today.

I do actually have the bypass key switched off, and that's another function the back end form provides - if you get the password wrong, the database just closes (and you can't bypass the form), but if you get it right, it stays open, and also prompts to ask if you want to enable the bypass key as well (so if I am working on it, I don't have to enter the password every time I need to close/reopen it). Another button on the form disables the bypass key again.

I may just nuke the form altogether as you've suggested. I didn't know you could enable the bypass key on a database from outside a database, but I guess you must be able to since this is what you're implying by nuking the form and keeping the bypass disabled. I'll do some more research on that approach too.

Thanks again.

 

[Buj]

Thanks David. I've read these articles and others, and I'm now hyperventilating. I have about 9 replicas all of which are being managed in exactly the same scenario as you've used as an example of what not to do in your Wiki article - users update them offline and send them back to me for synching.

I did do some testing with this setup before I decided to use it, and it seemed to work fine. Obviously though, stuff was going on of which I wasn't aware... I'm also pretty annoyed at the MS Access help on replication. On having another look at it just now, all I can find to say that you can't do this, is one line saying indirect synchronization can only be done via the Replication Manager. I had originally assumed (stupidly?) that the Replication Manager is the set of tools you get within Access under the Replication menu! You'd think there'd be flashing warning lights...

Luckily this is my first synch, so you may have averted a disaster by directing me to your Wiki before I put the replicas back out there. I opened the MSysReplicas table and there are about 50 records in there despite there only being 9 replicas (from my point of view), so obviously the moving around/renaming is spawning new replicas, as you've said would happen.

However, MSysSideTables only lists the conflict (due to the back end form?) I reported in my original post (after synching, the biggest table has about 500 records, and none of of the other tables caused synch problems). Can I just get some clarification on what you said in your Wiki article: that multiple replicas (of the same replica) may not be a problem unless there are conflicts that aren't resolved, and then the replicas are sent back out. Does that mean that if any conflicts are resolved before putting the replicas back out, that I may still be able to get away with this? And does Access tell you about all conflicts if you synch using the Access UI, or do you have to go looking in MSysSideTablesto see if it automatically made some decisions based on its priority rules?

I'm guessing I won't be able to get away with it, but I was hoping to avoid having to recreate all the indexes and relationships... what a drag!

Thanks again.

 

[dfenton]

However, MSysSideTables only lists the conflict (due to the back end form?) I reported in my original post (after synching, the biggest table has about 500 records, and none of of the other tables caused synch problems). Can I just get some clarification on what you said in your Wiki article: that multiple replicas (of the same replica) may not be a problem unless there are conflicts that aren't resolved, and then the replicas are sent back out. Does that mean that if any conflicts are resolved before putting the replicas back out, that I may still be able to get away with this? And does Access tell you about all conflicts if you synch using the Access UI, or do you have to go looking in MSysSideTablesto see if it automatically made some decisions based on its priority rules?

You should be able to chase this down by looking at the ReplicaID that produced the conflict. Then you need to see if any of your 9 existing replicas have that ReplicaID. If so, then you can resolve the conflict. If not, then you're stuck, unless you're allowed to delete the conflict record. You'd want to look for a table named MSysAccessStorage_Conflicts and that should have the losing conflict record in it. If you delete that record, the conflict is gone (all resolving conflicts with the conflict resolver ever does is delete that record if the conflict was correctly resolved, or copy the conflict record's data into the winning record and then delete the conflict record).

But since it's a system table, you may not be allowed to delete the record. If the source replica has been lost (from copying around), then you have a conflict that can never be fixed.

I'm guessing I won't be able to get away with it, but I was hoping to avoid having to recreate all the indexes and relationships... what a drag!

You shouldn't need to start over -- you can synch all your replicas then unreplicate (see Question 10 of the Jet Replication Wiki FAQ), and then re-replicate -- no need to completely rebuild the table structures from scratch.