Briefcase.....more like griefcase!

[Rachael]

Hi All,

Does briefcase become corrupt? Probably a silly question but...

My client has been happily using a front end / backend for sometime. He drags the backend to the briefcase causing the replication thing to happen then over a network drive, moves the briefcase to a Targatech(I think) mobile tablet (mini computer running windows etc) which is used for field data entry. At the end of the day the staff bring the tablet back and sync the data back using the briefcase...no problems.

Yesterday I sent an update of the frontend, which modified a field type in one of the tables using this code:

Set db = OpenDatabase(strConnect)
For I = db.Relations.Count - 1 To 0 Step -1
If (db.Relations(I).Table = "Vintage1") Then
db.Relations.Delete (db.Relations(I).Name)
End If
Next I

db.TableDefs.Delete ("Vintage1")
Set db = CurrentDb

DoCmd.TransferDatabase acExport, "Microsoft Access", strConnect, acTable, "Vintage8_9Exp", "Vintage1", False

Dim newvint As TableDef
Dim strvint As String
strvint = "Vintage1"
Set newvint = dbLink.TableDefs(strvint)
newvint.Connect = ";DATABASE=" & strConnect
newvint.RefreshLink


There are probably some Dim's missing from the top of the code which i didn't worry about pasting here as there's quite a bit to look thru.

Anyway the above method I've used for about 6 years, no worries...what I am worried about is that now the clients backend is replicated am I changed a table that its causing problems.

I told the client that he should ditch the old breifcase and make a new one 'cos I'd chaged the backend...but now the code I have for the frontend won't link to the backend in the breifcase, it will link when sitting around on the computer somewhere but not in the breifcase. The error is relating to not being able to find correct tables.

I've probably gone a long winded way of asking 'can a briefcase become corrupt and need repairing' but wanted to have all the info to consider.

Thank you very much for any who have a look at my problem

kind regards,

Rachael

 

[Rachael]

PS. The only thing that makes me think briefcase is not the problem is the client has two of the mini computer tablets and it happens on both.

Also I'm concerned about these extra fields replication adds, the s_GUID S_Lineage etc etc when I made the new table from the original table I didn't include them thinking that when the client made a new briefcase they would be automatically made again

 

[Rachael]

PPS The relinking code in my frontend will link to a breifcase on my computer

 

[Rachael]

ppps Sorry I keep forgetting to say things, I'm using Acc 2007 frontend and Acc 2000 backend

 

[boblarson]

Briefcase should not be used with an Access database.

 

[Rachael]

Thanks Bob, So no Briefcase...what would you suggest as an alternative?

and just quietly I would be glad to find an alternative to the 'Griefcase'

Thank you, Rachael

 

[dfenton]

Briefcase replication does work with Access, but it makes your app replicated. This means you can't make design changes to the replicated MDB except at whichever copy is the Design Master.

I would certainly recommend against using briefcase replication, since it's mostly been abandoned by MS.

However, all is not lost -- you can program the synch yourself, so that the user synchs by clicking a button in the app (instead of by dragging to and from the Briefcase).

 

[Rachael]

Hi David,

Thank you for your reply, I have picked up on the tsi synchronizer dll and have begun including this in my app and must say am pleased so far in that the synch part becomes part of my app rather than a routine using another thing ie briefcase.

You said briefcase 'makes your app replicated' and I thought there was no other way to make an app synchronize without replicating it. The tsi synchronsinzer replicates as well....are there other methods to synch?

Thank you so much for your help

kind regards,

Rachael

 

[dfenton]

I don't see why you need the TSI Synchronizer. Access itself provides the functionality for direct replication. And the TSI Synchronizer by itself does not provide the Jet Synchronizer, so you can't do indirect synchs with just it.

I think there is some fundamental misunderstanding on your part of what replication is and what it is for. Jet Replication's purpose is to allow you to edit one database in two locations and merge the changes from both via a synchronization operation.

When you create an Access MDB, it is not replicated. That is, it cannot be synchronized with other copies of itself. If you replicate your MDB, then the different copies (i.e., replicas) of your MDB can be synchronizes with each other. When you drag an MDB to the Windows Briefcase, it is replicated, and then the synchronization is done behind the scenes via Jet replication's synchronization methods.

Now, if you actually *want* to edit the data in more than one location, then replication is useful. If you don't, then it serves no purpose whatsoever.

Given that explanation, do you need and want to use Jet Replication or not?

 

[boblarson]

And actually the replication (both regular and briefcase) should only occur with a backend db and not with databases (FE or Standalone) that have forms, reports, macros and VBA modules. Using replication with those almost guarantees corruption at some point in time (at least that is from what I've found).

 

[Rachael]

Hi Bob and David, thank you so much for your replies. I think I do understand replication and am sure I need it. My client whom I working with at the moment needs to be able to load the database onto Tablet PC's for out in the field data entry, they also have an office network which at the moment about 3-4 people are connected to a back end located on their network drive.

I do understand that frontends don't need to be replicated and so far have only been replicating the backend using the "Griefcase". I have been getting the client to make a briefcase for each tablet (3 in total), taking it to the tablet via their network, then sync'ing back at the end of the days paddock data entry. This all worked OK for quite awhile until I added some new tables to the backend (I'm hoping it was the DM and am not sure how to tell if it was or not). Anyway I then told the client to make new briefcases and drag the backend with new tables in it thinking this will replicate the new tables etc. Now the tablets will not link to the new briefcase backend versions when in the briefcase but would if it was taken out of the briefcase.

So...what I did next was scrap briefcase and start using the TSI synchroniser (which is a much better solution for the client in the long run as it seems much less complicated, also we plan to commercialize the product once fully tested so was gunna go down this path at some stage anyway, the learning curve is steep at the moment...).

To cut a long story short, the tablets will still not link to the replica and trip out at the newly addded tables. Is there anything I should know about adding tables to backends, I'm sure it should only be done at design master but I'm not sure the client would even know which one is the DM, how can I check and if it's lost, how can I roll back a replica (if at all)?

Thank you so much for your deliberance of my questions.

Kind regards,

Rachael

 

[dfenton]

I don't know if you can use the Briefcase on multiple computers. It was designed for a single user to copy data from one computer to another and back again. With multiple users, I'm not sure it will work reliably (though it might).

I'd get away from the briefcase as quickly as possible, as it's not documented and not programmable.

I still don't see what you need the TSI Synchronizer for. If Briefcase was adequate at one point, then you only needed direct replication, and you have no need for any components outside of Access to do direct replication. So, if you're going to commercialize your app, you'd be *much* better off not having a dependency on the TSI Synchronizer (or any other outside component).

In regard to your main question, you wrote:
> To cut a long story short, the tablets will still not
> link to the replica and trip out at the newly addded
> tables.

Are the tables in the replicas? If not, then your synch of the design changes is not succeeding. Either you have a design error blocking the synch, or you are synching with the wrong replica (or, put another way, *linking* with the wrong replica).

> Is there anything I should know about
> adding tables to backends, I'm sure it should only
> be done at design master

It can *only* be done in the DM. You can't make any design changes to replicated objects in any replica *but* the DM. If you are adding tables to a non-DM, then that would explain why they aren't synching, because they aren't replicated, and *can't* be replicated under any circumstances.

> but I'm not sure the
> client would even know which one is the DM, how
> can I check and if it's lost, how can I roll back a
> replica (if at all)?

There's only one DM and the DM should be on the server. If you don't know what replica is the DM and where it's located, then you are unlikely to succeed at implementing design changes to the structure of your data tables.

And by "roll back a replica" what do you mean? A replica once created can be deleted. To clean up the replication tables it has to be deleted from the replica set, which is accomplished by attempting a synch with the deleted replica (it's actually more complicated than that to completely clean up the replica set, i.e., to clear any record of the deleted replica, but that's the main thing), which deletes it from the canonical list of replicas in MSysReplicas. Deleting it from one replica may or may not propagate to other replicas -- it depends on a number of things.

If you're going to resolve the problem, you really need to get in hand on what is the DM, where it is located (on the server) and what replicas are on the tablet PCs (you should have only one on each tablet in order to keep things simple at the start, though you may add some backup replicas for your final app just for safety). There is no point in coding this -- it's really something that is most easily done by actually examining the setup in person.

I would also strongly suggest that you need a lot more planning and preparation before you contemplate selling this to anyone. If you can't get this right in one situation, you're going to be buying yourself all kinds of awful problems if you present it to potential buyers as a working solution.

 

[Rachael]

Hi David, thank you so much for your time and thoughts, I must say I'm entering new territory here and agree I need to do alot more planning hence my reason for posting in this forum, I really appreciate yours and anyone else help.

I guess I think I need the TSI synchronizer for the future where indirect and internet synch'ing can be utilised. I'm sorry if I'm sounding really dumb on this, I'm on a steep learning curve and hope I'm smart enough to figure it all out.

The plan for this app is to have an easy to use (for farmers, they like steering wheels not keyboards usually) method to manage replicas that will be used on tablet PC's, laptops and (hopefully) internet (although no idea how this would work yet). I have ideas on how all this should be structured but would really love your feedback. My prgramming skills are only average. Sorry to take your time up but could you point me in the right direction, I would even be willing to pay someone for a sound solution.

Kind regards,

Rachael

 

[Rachael]

I think I might make a new thread as I'm getting off the original topic.

"Setting up for Replication"

 

[dfenton]

I'm glad my rather blunt reply seems not to have offended you. After I posted it I thought I should perhaps have been a little more diplomatic.

The situation you described (so far as I'm understanding it) was with tablet PCs that are brought into a central location and connected to the LAN there. In that environment, you don't need anything but direct replication, which can be done via the DAO Synchronize method.

It's only when you need to synch across the Internet that you need something else, and for that I'd recommend indirect over Internet replication simply because Internet replication requires an IIS web server as the replication hub, while indirect has no such outside dependency.

I would suggest you get the direct replication up and running first, where the users connect to the LAN and synch. Once that's working, you can implement the indirect replication, which is orders of magnitude more complex.

Have you read through my Jet Replication Wiki?

http://dfenton.com/DFA/Replication/

It's not just for experts -- newbies are welcome to sign up for an account and create subjects that they'd like someone else to explain. And it would probably be good if some of the content were written from the point of view of people like you who are new to the subject. I've been at it since 1997 so a lot of the concepts are so second nature to me that they can become invisible to me, and that makes it terribly difficult to answer questions from people like you helpfully.

Anyway, I'll look at your new thread and try to help there.